Sunteți pe pagina 1din 144

Connectivity

Alliance Access 7.1


On Alliance Web Platform

Security Guide
This security guide describes the security-related features of Alliance Access. It outlines the aspects of security that an
Alliance Security Officer must consider to protect Alliance Access and its operating environment from security threats. It
also describes the controls that an Alliance Security Officer can implement, such as common backup strategies to protect
against system failure.

This security guide is written specifically for an Alliance Security Officer, and anyone who is responsible for operational
and computer security will find its contents useful.

27 March 2015
Alliance Access 7.1 on Alliance Web Platform

Table of Contents

.Preface .............................................................................................................................................................................4

1 Training for SWIFT Users ............................................................................................................................ 5

2 Security of Alliance Access ....................................................................................................................... 6


2.1 Description of an Alliance Security Officer ............................................................................................ 6
2.2 Tasks of an Alliance Security Officer (LSO and RSO) ........................................................................ 6
2.3 Preparing for a Security Role .................................................................................................................. 7

3 Security Aspects to Consider ................................................................................................................... 8


3.1 Terms and Definitions ............................................................................................................................... 8
3.2 Overview of the Alliance Web Platform ................................................................................................. 9
3.3 Security Features of Alliance Access ................................................................................................... 12
3.4 Customer Security Controls ................................................................................................................... 15
3.5 Addressing Additional Vulnerabilities in Web-Based Applications .................................................. 18
3.6 Security on AIX, Linux, or Solaris Systems ......................................................................................... 21
3.7 Security on Windows Systems .............................................................................................................. 30
3.8 Alliance Access Operating Modes ........................................................................................................ 33
3.9 Offline Maintenance Utilities .................................................................................................................. 35

4 Installation, Upgrade, and Licensing ................................................................................................... 37


4.1 What Is Secure Channel? ...................................................................................................................... 37
4.2 Alliance Initialisation Password ............................................................................................................. 37
4.3 Alliance Master Password ..................................................................................................................... 38
4.4 Sign-on Time Limits ................................................................................................................................ 39

5 Configuration and Security Parameters ............................................................................................. 41


5.1 Classes of Configuration Parameters .................................................................................................. 41
5.2 Security Parameters ............................................................................................................................... 55

6 User Management ......................................................................................................................................... 69


6.1 Management of User Accounts ............................................................................................................. 69
6.2 Alliance Password Modes ...................................................................................................................... 70
6.3 Password Renewal ................................................................................................................................. 71
6.4 Resetting User Passwords .................................................................................................................... 71
6.5 Defining Alliance Access Operators ..................................................................................................... 71
6.6 Support for Service Bureau ................................................................................................................... 72
6.7 Profiles in a Sample Service Bureau ................................................................................................... 74
6.8 Operators and Users of Alliance Access ............................................................................................. 75
6.9 Using Operator Profiles .......................................................................................................................... 79
6.10 Definition of Units and Restrict Functions ........................................................................................... 80
6.11 Authentication Server Groups and One-Time Passwords ................................................................ 81
6.12 Password Controls .................................................................................................................................. 82

2 Security Guide
Table of Contents

7 Default Operator Profiles ........................................................................................................................... 84


7.1 Overview of Default Operator Profiles ................................................................................................. 84
7.2 Access Control Application .................................................................................................................... 86
7.3 Application Interface Application ........................................................................................................... 87
7.4 Calendar Application ............................................................................................................................... 90
7.5 Correspondent Information File Application ........................................................................................ 90
7.6 CRnet Interface Application ................................................................................................................... 92
7.7 Event Log ................................................................................................................................................. 92
7.8 Integ. Platform Application ..................................................................................................................... 93
7.9 Message Approval Application .............................................................................................................. 94
7.10 Message Creation Application .............................................................................................................. 96
7.11 Message Modification Application ........................................................................................................ 98
7.12 Message File Application ..................................................................................................................... 100
7.13 Monitoring Application .......................................................................................................................... 102
7.14 Relationship Management Application .............................................................................................. 103
7.15 Reporting Application ........................................................................................................................... 107
7.16 Routing Application ............................................................................................................................... 107
7.17 Security Definition Application ............................................................................................................. 108
7.18 SWIFT Interface Application ................................................................................................................ 109
7.19 SWIFT Support Application ................................................................................................................. 110
7.20 SWIFTNet Interface Application ......................................................................................................... 112
7.21 SWIFTNet Support Application ........................................................................................................... 114
7.22 System Management Application ....................................................................................................... 114

8 Securing System Resources ................................................................................................................. 117


8.1 Backup Strategies ................................................................................................................................. 117
8.2 Software and Data Integrity ................................................................................................................. 119
8.3 Software Integrity .................................................................................................................................. 120
8.4 Data Integrity Checking ........................................................................................................................ 122
8.5 Encryption of Secret Data .................................................................................................................... 123
8.6 Minimising the Impact of System Failure ........................................................................................... 126

9 Controlling Message Processing ......................................................................................................... 130


9.1 Message Preparation Controls ........................................................................................................... 132
9.2 Other Message Processing Controls ................................................................................................. 136
9.3 Application Interface Controls ............................................................................................................. 140
9.4 CRnet Interface Controls ..................................................................................................................... 143
.Legal Notices .............................................................................................................................................................144

27 March 2015 3
Alliance Access 7.1 on Alliance Web Platform

Preface
Purpose of the document
This Security Guide provides:

a description of all of the security-related features of Alliance Access and Alliance Web
Platform

a reference document for Alliance Security Officers, who are involved with or responsible for
operational and computer security
For security details of Alliance Workstation, refer to the Security Guide for Alliance Workstation.

Audience
This document is aimed at those personnel who influence either the security policies or the
implementation and management of security controls within their organisation or business.

Significant changes from the previous version


This document has been reorganised to emphasise the following:

specific information regarding the Alliance Web Platform

tasks and responsibilities of the Alliance Security Officer

Feedback on This Document


This is a new version of this document and your feedback is welcome. Please provide any
feedback by means of SWIFT Support.

4 Security Guide
Training for SWIFT Users

1 Training for SWIFT Users


Overview
SWIFT Training is your first point of contact for learning how to use SWIFT standards, products,
and services accurately and effectively. Training is available to all SWIFT users.

Related courses
SWIFT recommends the following Alliance Access courses. For full descriptions, consult the
Training pages on swift.com:

Operating Alliance Access and Entry

Managing Alliance Access and Entry

Deploying Alliance Access

Optimising Your Alliance Resilience

Alliance - Disaster Recovery

SWIFT Audit Guidelines


To view the full training portfolio that SWIFT offers, see www.swift.com > Training > Training
topics.

How to register for training


To register for SWIFT Training, visit www.swift.com/training. You must have a swift.com user
name and password to register for SWIFT Training. If you do not have a swift.com user name
and password, register at swift.com. Instructions will be sent to you by e-mail.

27 March 2015 5
Alliance Access 7.1 on Alliance Web Platform

2 Security of Alliance Access


Introduction
This section describes the security aspects that an Alliance Security Officer must consider when
selecting the security controls to implement to protect Alliance Access and its environment from
security threats.

2.1 Description of an Alliance Security Officer


Overview
An Alliance Security Officer has a key role in configuring and managing the security functions
within Alliance Access. The Alliance Security Officer must work with auditors, SWIFTNet
Security Officers, project teams, system administrators, and anyone else within the institution
who is responsible for ensuring that the environment in which the business and applications
operate is secure and protected against security threats.

There are two security officers, the left security officer (LSO) and the right security officer
(RSO). Together they control which users can sign on to Alliance Access and what those users
are permitted to do.
SWIFT has predefined the actions that Alliance Security Officers can perform within Alliance
Access. You cannot change those pre-defined entitlements and permissions.
In a service bureau and other multi-BIC environments, with the correct security parameter set,
the left security officer and right security officer can create "local" security officers for each of the
SWIFT institutions, which effectively delegates part of the security officers' authority.

2.2 Tasks of an Alliance Security Officer (LSO and


RSO)
Overview
Both Alliance Security Officers (LSO and RSO) perform the following tasks:

Obtain the licence and passwords for Alliance Access from the Secure Channel. For more
information, refer to "What Is Secure Channel?" on page 37.

Enter their password during the installation, upgrade or relicensing of the Alliance Access
software, and also in the creation of user accounts in Alliance Access. For more information,
refer to "Alliance Initialisation Password" on page 37.

Reset the password of the other Alliance Security Officer, if required and permitted. For more
information, refer to "Alliance Master Password" on page 38.

Manage operator profiles. An operator profile is a set of permissions that you can assign to a
specific type of user. For more information, refer to "Defining Alliance Access Operators" on
page 71.

Manage user accounts, passwords, and sign-ons. You can delegate this task within your
institution, if required. For more information, refer to "Management of User Accounts" on
page 69.

6 Security Guide
Security of Alliance Access

Configure security parameters and the use of passwords. For more information, refer to
"Classes of Security Parameters" on page 56.

Approve routing schemas. A routing schema controls how messages are handled and routed
within Alliance Access. For more information, refer to "Routing Application" on page 107.

Work with the Operating System Administrator and Alliance Administrator to ensure that the
system on which Alliance Access runs is secure and resilient. For more information, refer to
"Security Aspects to Consider" on page 8.

Monitor the activities of the users of Alliance Access for any security-related risks or threats.
For more information, depending on your operating system, refer to "Security on AIX, Linux,
or Solaris Systems" on page 21 or "Security on Windows Systems" on page 30.
Security officers are not entitled to perform operational duties, such as sending and receiving
messages. This ensures that operational and security-related duties are kept strictly separate.
This guide provides an overview of the tasks that an Alliance Security Officer performs.

2.3 Preparing for a Security Role


Knowledge Required
If you are new to the role of Alliance Security Officer, then the following guides provide useful
background information about the tasks that you perform on Alliance Access:

Alliance Access Administration Guide

Alliance Access Configuration Guide

SWIFTNet Certificate Administration Guide

SWIFTNet Service Description

Alliance Access Service Description

Hardware Security Module Operations Guide

Related Training
If you are new to the role of Alliance Security Officer, then you may be interested in attending
the following training courses:

Managing Alliance Web Platform

Managing Alliance Access

PKI for SWIFTNet Security Officers


For a complete list of SWIFT's training offerings, go to http://www.swift.com/training/index.page?
lang=en.

27 March 2015 7
Alliance Access 7.1 on Alliance Web Platform

3 Security Aspects to Consider

3.1 Terms and Definitions


Throughout this guide, several special terms are used to describe the different aspects of
security. To avoid possible confusion, those terms are defined here. They describe the basic
requirements for information security, and for the security of systems that process information.

Security term Definition

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 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 Implies that both the information and the systems used to process, display, print
and so on that information be 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 his or her own 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. Similarly, a computer system must be
held responsible for automated actions, and log files maintained accordingly.

When configuring and administering information systems, the following principles assist greatly
in ensuring the basis of a security system:

Security principle Definition

Need-To-Know Information and resources must only be made available strictly on a need-to-
know basis.
Alliance Access ensures that operators only have access to the information,
files, and system resources necessary for their defined tasks. Access to other
system functions is barred.

Least Privilege Users must only be granted the minimum level of privileges required for them to
perform their normal tasks.
Alliance Access ensures that operator privileges are controlled in a way which
allows all privileges to be tailored to individual needs.

8 Security Guide
Security Aspects to Consider

Security principle Definition

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, must also be logged.
Alliance Access provides a comprehensive event logging facility which logs all
operator and system events that occur within Alliance Access.
On an exceptional basis, for example, in an emergency, normally inaccessible
information may be made available, or higher privileges may be granted to
users but always in a controlled manner.
It is important to realise that the implementation of these principles may create
restrictions for users in the use of their systems. However, these restrictions are
necessary to protect against accidental damage caused by inexperienced staff,
as well as to protect against malicious attacks.

3.2 Overview of the Alliance Web Platform


Overview
This section provides an overview of the functionality and available versions of the Alliance Web
Platform.

3.2.1 Alliance Web Platform


Description
The Alliance Web Platform is the framework that hosts the browser-based graphical user
interfaces (GUIs) of the Alliance portfolio and that replaces Alliance Workstation. It offers a
consistent end-user interface to the functionality managed by the Alliance Access servers.
Alliance Web Platform runs in an application server environment, enabling centralised
deployment of the software.

Versions
The Alliance Web Platform is delivered in two versions:

One version requires a web application server (IBM WebSphere Application Server) that can
be configured in a cluster to provide robust operational capacity, such as load balancing and
resilience mechanisms.

The other version (Alliance Web Platform Server-Embedded) includes the application server
that the software requires.
In addition, the Alliance Web Platform enables access to the Browse services provided by third-
party service providers (typically market infrastructures) on SWIFTNet.
For more information about the Alliance Web Platform, see www.swift.com > Products &
services > Web Platform, Alliance > Details.

3.2.2 Alliance Web Platform as GUI for Alliance Servers


The Alliance Web Platform provides a common set of services to all GUI applications
(packages) deployed in it. The packages deployed in the Alliance Web Platform include:

Configuration

27 March 2015 9
Alliance Access 7.1 on Alliance Web Platform

Message Management

Monitoring

Relationship Management
An Alliance Web Platform package is accessed by users using their browser. The Alliance Web
Platform then interacts with the Alliance Access Server to provide the services requested by the
user.

Overview of Alliance Web Platform

Alliance Web Platform


Application Server
Alliance Integrator

Platform DB
Platform
JDBC

Browser
Alliance Gateway
Alliance Web Platform
WebPage Administration Package
HTTPS
GUI Alliance
Application Access/Entry
(Package)

D1350003
Note Alliance Integrator and Alliance Gateway are not discussed in this document. Refer
to the respective product documentation for more details on these products.

The Alliance Web Platform manages its own data store (platform database) to maintain
configuration and monitoring data. Management of the configuration data of the Alliance Web
Platform and basic GUI administration functions are performed by means of the Alliance Web
Platform Administration package. The Alliance Web Platform Administration package is
accessed in the same way as any other package that is registered for the Alliance Web
Platform.

10 Security Guide
Security Aspects to Consider

Overview of Alliance Access

File Transfer
MQ Workstation Internet
SOAP Explorer
Web Services Direct FileAct
Web Platform
ADK CAS

Application Back-Office Desktop


Integration
Integration Application Access

Messaging Alliance Access Packages


Software
Configuration

Monitoring

Message Management

Relationship Management

Communications Alliance Gateway


Software

Network
Connection

FIN
SWIFTNet InterAct D0540209
FileAct

The following table outlines the entities that are contained in each of the Alliance Access GUI
applications (packages), as shown in the preceding graphic. For more information about default
operator profiles, entitlements and entities, see "Default Operator Profiles" on page 84.

Alliance Access GUI Applications (Packages)

Entities Configuration Monitoring Message Relationship


Management Management

Access Control

Application
Interface

Calendar

Correspondent
Information File

Event Log

27 March 2015 11
Alliance Access 7.1 on Alliance Web Platform

Message Approval

Message Creation

Message
Modification

Message File

Monitoring

Relationship
Management

Routing

Security Definition

SWIFT Interface

SWIFT Support

SWIFTNet
Interface

SWIFTNet Support

System
Management

3.3 Security Features of Alliance Access


3.3.1 Authentication and Session
The Alliance Access server authenticates the users who connect to Alliance Access through the
Alliance Web Platform. Administrators use the Alliance Web Platform Administration package
are authenticated against the user registry of the application server.
Whenever the browser connects to Alliance Web Platform to perform a logon, 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, the Alliance Web Platform performs the validation of the user credentials
against the Alliance Access Server. Upon successful validation, the Alliance Web Platform
generates a user context identifier that is returned to the browser:

Server Side
Alliance Web Platform is authenticated using an SSL server certificate, which can be signed
by a trusted third party. SWIFT recommends using a recognised Certification Authority (CA)
or a Certification Authority under the customer's control.

Client Side
By default, an end user is authenticated towards the back-end Alliance Access Server using
a UID or 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 (for example, Alliance Access, Alliance Gateway).
In addition, for some Alliance products, SWIFT provides the option to use a One-Time-
Password (OTP) using hardware tokens or authentication by means of an LDAP server.
These options should be considered when using Alliance in a non-trusted environment.

12 Security Guide
Security Aspects to Consider

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 Alliance Web Platform verifies the user context identifier for every user
request.

3.3.2 Server Authentication and Confidentiality


All network traffic is encrypted using Secure Socket Layer (SSL) one-way authentication. This
feature ensures confidentiality on the network and protects against replay attacks, which is a
form of network attack in which a valid data transmission is maliciously or fraudulently repeated
or delayed.
The communication between an Alliance Web Platform package and the server is secured by
Secure Socket Layer, ensuring the confidentiality of the operator user name and password
exchanged between the Alliance 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.

Note To avoid SSLv3 (CVE-2014-3566 - POODLE) vulnerability, SWIFT recommends


that you disable SSL encryption in your browser settings to access SWIFT
products and services. By doing so, you will eliminate any residual risk that this
SSLv3 vulnerability may cause.
Before disabling SSLv3, SWIFT recommends that you test the compatibility of TLS
with all of your various Browse services. For information on configuring the browser
to use TLS, see Web browser settings in the Alliance Web Platform Installation
Guide for AIX, Linux, Oracle Solaris, or Windows. If you encounter difficulties
reaching a Browse service, consult with the relevant service provider.
SWIFT will cease to accept SSLv3 encryption for browser connections in early
2015.

3.3.3 Four-Eyes Control and Approval


Alliance products provide a large panel of authorisations options, such as the segregation of
roles, units, and duties; four-eyes control over critical security operations; and six-eyes control
for the sending of messages (creation, verification, and authorisation) to manage user
privileges. These features allow applying the least-privilege principle and thus reinforcing the
application security.
The authorisations are not enforced at the Alliance Web Platform level, but rather at the back-
end server level, where the processes that the web client communicates with reside (the same
as for authentication). This architecture minimises the impact of an attack on the Alliance Web
Platform by mitigating the risk of the user authorisations mechanism.

27 March 2015 13
Alliance Access 7.1 on Alliance Web Platform

3.3.4 Summary of Security Officer Tasks and Alliance Access


Features
Summary
The following table summarises the tasks assigned to Alliance Security Officers and the related
features in Alliance Access.

Key Security Features of Alliance Access

Alliance Security Authentication and Server Authentication Four-Eyes Control and


Officer Task Session and Confidentiality Approval

Obtain the license and


passwords for Alliance
Access from the Secure
Channel

Enter a password during


the installation, upgrade
or relicensing of the
Alliance Access
software, and also in the
creation of user
accounts in Alliance
Access

Reset the password of


the other Alliance
Security Officer, if
required and permitted

Manage operator
profiles

Manage user accounts,


passwords and sign-ons

Configure security
parameters and the use
of passwords

Approve routing
schemas

Along with the


Operating System
Administrator and
Alliance Administrator,
ensure that the system
on which Alliance
Access runs is secure
and resilient

Monitor the activities of


the users of Alliance
Access for any security-
related risks or threats

14 Security Guide
Security Aspects to Consider

3.4 Customer Security Controls


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 non-web clients to the Alliance Web Platform.
Alliance Web Platform is designed to be implemented in a secure customer environment. This
assumes that a minimum set of controls is implemented at the customer site, as outlined in
"Recommendations" on page 17.
The physical and logical security of the computer and the 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.4.1 Customer Infrastructure


Customers must consider the following controls at the infrastructure level:

Secure Server Environment

Physically and logically protect the server running Alliance products.

Ensure that the operating system on which each Alliance product runs is appropriately
configured according to the vendor recommendations, and only install authorised and
required software / applications. For more information, see the OS Levels and Patches
Baseline document, which is available at www.swift.com, and the Release Letter for
Alliance Access.

Ensure that the application server (that is, IBM WebSphere) is appropriately configured
based on the recommendation by the vendor.

Ensure that all system software is 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 access to the PC.

3.4.2 Secure Browsing


From a practices point of view, the customer must ensure that users are following secure
browsing practices, such as:

Segregated general browsing from Alliance Web Platform either by using different Windows
accounts or, ideally, by using different PCs.

27 March 2015 15
Alliance Access 7.1 on Alliance Web Platform

Not browsing sites other than Alliance Web Platform when an Alliance session is open.

Never following links in e-mails that would pretend to direct the user to Alliance Web
Platform.

Security awareness for Alliance end users, which allows for the development and
maintenance of secure-minded behaviour in the user base and which ensures that users are
fully aware of threats related to browsing (such as ensuring that PC user sessions cannot be
taken over).

3.4.3 Network Segregation


Alliance product design provides the flexibility for customer to implement adequate network
segregation in line with best practices. Alliance Web Platform can be implemented in a De-
Militarised Zone (DMZ). This allows for 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, a TCP-based SWIFT proprietary transport protocol) based on
Secure Socket Layer (SSL)

between Alliance Web Platform and Alliance Access or Access 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 by means of un-trusted networks.

3.4.4 Front-End Reverse Proxy


Alliance Web Platform is running on top of several third-party products. Over time, those
products can have vulnerabilities that are 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 (that is, a configuration type 2 cluster with an HTTP server front end).

3.4.5 Account Management and Segregation of Duties


The least privilege and segregation of duties principles must always be considered when
defining user profiles. This is not specific to Alliance Web Platform, because 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 (that
is, messages to be sent over SWIFTNet).
In addition, all actions performed by means of Alliance Web Platform must be adequately
monitored to maintain efficient accountability. This can be performed using the monitoring and
logging features provided by the different Alliance Access Servers.

16 Security Guide
Security Aspects to Consider

3.4.6 Migrating to Alliance Web Platform


The only change of security practices in the customer's SWIFT environment can be linked to the
fact that, unlike non-web-client architecture, users can access Alliance interfaces from any
desktop with a browser installed.
If non-web-client software has been used as a control by your organisation, network
segregation and firewalls can achieve the same security objective by allowing only dedicated
PCs to access Alliance Web Platform.

3.4.7 Alliance Web Platform in a Non-Secure Environment


Alliance products are designed to be implemented in a secure customer environment, as
outlined in "Recommendations" on page 17.
When Alliance Web Platform is directly exposed to an insecure network such as the Internet,
the security risk is considered higher due to an increase in likelihood of existing attacks. This is
inherent in the usage of uncontrolled networks such as the Internet. Even though the product
allows such a deployment; this set-up is not recommended by SWIFT.
If you decide to operate Alliance Web Platform in such a configuration, then 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 can always be used, which
creates an additional layer of security between the client and the server premises. In this
context, Alliance Web Platform is no longer directly exposed to a non-trusted network.

3.4.8 Recommendations
This section lists typical SWIFT recommendations for Alliance users. However, this is not an
exhaustive list, and Alliance Web Platform users should implement complementary security
measures where and when justified by their own security risk analysis.
SWIFT recommends that you:

Install and manage a firewall facing the Internet, that does not accept 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 that is
continuously active and kept up-to-date with the latest threats.

Restrict outgoing traffic of the PC to business-critical sites (in addition to legitimate sites
required for software updates).

Ensure that the PC used for accessing Alliance is physically and logically accessible only by
the person entitled to access this PC.

27 March 2015 17
Alliance Access 7.1 on Alliance Web Platform

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, and any additional features (called plug-ins).

Reserve PCs to accessing internal sites of the same criticality as Alliance, and only access
these sites from these PCs.

Set up end-user management practices that ensure that only authorised end users are
created, and that the list of authorised end users is kept up-to-date as users change roles or
leave the company.

Use entitlement management practices that ensure 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 the Alliance Web Platform
application.
On the other hand, SWIFT recommends that you:

Do not browse the Internet from the PC where you access critical Alliance functionality.

Do not browse any other site at the time that you access the Alliance Web Platform
application, up until you have ended your session.

Never write down any passwords.

Never communicate your password to anyone.

Do not follow a hyperlink contained in an e-mail, even if that URL seems perfectly valid from
a business perspective. Instead, once you have confirmed the business need to visit that site,
re- type the URL within the browser as it was visible in the mail. Such phishing attacks may
lead to rogue sites that can steal information or infect your PC.

Never accept a pop-up asking that you to download and install executables.

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

3.5 Addressing Additional Vulnerabilities in Web-


Based Applications
When deploying any web-based application in the institutions, customers must be aware of the
vulnerabilities of this technology and how 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.

18 Security Guide
Security Aspects to Consider

3.5.1 Threats and Attacks


The deployment of Alliance Web Platform does not introduce new threats. However, 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 impersonations that affect message confidentiality and integrity

Alliance Web Platform host attacks due to third-party software weaknesses (because it is
accessible to a larger community, that is, the Internet)

Denial of Service (DoS) attacks that affect 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 to perform further attacks.

Phishing
Creating a replica of an existing "login page" to fool a user to capture financial information, or
credential data (passwords and so on). 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.

Sniffing
The 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. 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.
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 to limit the impact of malicious acts.
For Denial of Service attacks, unavailability impact must be evaluated by every institution.

27 March 2015 19
Alliance Access 7.1 on Alliance Web Platform

3.5.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 must 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.

Security Threat Controls

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

Session Strong Secure Protection of


Key logger mechanism Password Browsing the system
Session SSL Tunnel Policy practices used by
guessing OTP Alliance
Steal password product
or session Phishing Account
Shoulder management
surfing Session
Mechanism

Phishing SSL Tunnel SSL Tunnel Secure


Data
Browsing
eavesdropping Sniffing practices

Server Activating and Secure Network


authentication using dual Browsing segregation
authorisation practices Patch
Man-in-the- and management
Data tampering
middle segregation of
duty Logical and
procedures physical control
VPN

Reverse proxy Network


Third-party segregation
product DMZ
weakness Patch
management

Patch Patch Network


management management segregation
Reverse proxy Server
segregation
Denial of Protection of
Service (DoS) the system
used by
Alliance
product
VPN

For more information, see "Security on Windows Systems" on page 30 or "Security on AIX,
Linux, or Solaris Systems" on page 21, depending on your operating system.

20 Security Guide
Security Aspects to Consider

3.6 Security on AIX, Linux, or Solaris Systems


Overview
This section describes security considerations when running Alliance Access on an AIX, Linux,
or Solaris operating system.

3.6.1 AIX, Linux, or Solaris User Accounts


3.6.1.1 The Alliance Administration Account

Overview
At installation, Alliance Access prompts the installer for the name of the "Administrator" account,
the UNIX or Linux account to be used by the Alliance System Administrator.
The system offers the default name of all_adm. If you install additional Alliance instances, then
it is recommended to give each Alliance instance a different administration account name. For
example, the first instance can be given the name all_adm, the next instance, all_adm1, and
so on. The account is a captive account protected by a UNIX-level or Linux-level password that
must be known only to the Alliance System Administrator.
Having logged on to UNIX or Linux, the Alliance System Administrator enters a dedicated
graphical environment provided by the System Administration application from which the
administrator is able to start and stop the Alliance servers, and to use various functions
specifically provided to manage Alliance.

3.6.1.1.1 Accessing AIX, Linux, or Solaris as Administrator

Administrator access
The Alliance System Administrator also has access to the UNIX or Linux command line. Once
logged-in as administrator (and after selecting an instance - if multiple instances are installed),
the System Administration application appears. From the OS Configuration menu, the Xterm
command opens a UNIX or Linux shell window. From here the Alliance administrator can issue
UNIX or Linux commands.
For more information, see the Administration Guide for your AIX, Linux, or Oracle Solaris
operating system.

3.6.1.2 Comparison of Administrative Roles

Administrative roles
The following table compares the roles of the Alliance System Administrator (assuming that the
account for the Alliance Access instance has been given the account name "all_adm"') and
UNIX or Linux System Administrator ("root") as applied to the system configuration, installation,
and ongoing maintenance of the Alliance Interface.

Note The UNIX or Linux System Administrator may also be responsible for other system-
related tasks, not directly connected with the use of Alliance Access.

Function or Procedure all_adm root

Initial System Configuration:

Configure Dual Hardware options (if licensed)

27 March 2015 21
Alliance Access 7.1 on Alliance Web Platform

Function or Procedure all_adm root

Create default directories and file systems

Set file attributes

Define environment variables (for installation)

Software installation and uninstallation:

Run install program (1)

Perform licensing procedures (with security officers)

Set password mode

Remove software

Install and remove software patches

System Management:

Create new UNIX or Linux account

Set file attributes for new accounts

Modify user profile (new user)

Copy alliance_init to new user

Start the Alliance Access servers

Stop the Alliance Access servers

Kill Alliance Access processes

Check database consistency

Run Alliance security check

Use of the saa_bankquery tool (with Support)

Back up and restore:

Back up the release tree

Restore the release tree

Back up the database

Recover the database from backup tape

(1) The software can be installed with a non-root account, but specific preparatory actions are required beforehand.
For more information, see the Installation Guide for AIX, Linux, or Oracle Solaris.

3.6.1.3 Auditing User Activities

Auditing access
Most UNIX or Linux systems provide some form of logging facility that may be used as the basis
for auditing access to the system.
Log files typically record:

user names and logon times

logoff times

the identity of the terminal used

22 Security Guide
Security Aspects to Consider

for networks, the name of the host that the logon originated from
In addition, an accounting function may be used to record which commands have been run,
including:

the identity of the user

the name of the command

the time that the process was terminated


AIX provides a comprehensive audit function, potentially generating huge amounts of data on
the activities of a system. This function is not normally active but is used, at specific times, to
trace certain events in the system. By default, auditing is deactivated for Alliance Access.

3.6.2 AIX, Linux, or Solaris Passwords


Passwords
Standard UNIX or Linux access control consists of a password-protected logon. No criteria are
imposed on the choice of password. UNIX or Linux does not offer (or rarely offers):

inactivity time-out

password aging

control of password format

terminal-dependent logon

time-based access controls

action on repeated logon failures


UNIX or Linux passwords are encrypted using an encryption algorithm and diversified using one
of 4096 "salts", derived from the system time. The UNIX or Linux "crypt" algorithm is available
on the system.
Encrypted password values are stored in a file which is freely accessible by all users, making
them vulnerable to so-called dictionary attacks. These rely on the fact that most people select
passwords which are words that may be found in a dictionary. By encrypting common words,
and comparing the result with that stored in the password file, a determined intruder can
discover a user's password. This is one very good reason why not to select passwords that are
words found in a dictionary.
AIX uses hidden password files which are not accessible to normal users. In addition, Alliance
Access requires a separate (and independent) level of operator identification and
authentication, based on the use of a SWIFT-proprietary one-way encryption algorithm.
When a UNIX or Linux account is first created, the UNIX or Linux System Administrator assigns
an initial UNIX or Linux password and advises users how to change this password following a
first successful logon. Thereafter, it is the responsibility of individual users to update any
passwords in line with local security requirements.
In relation to Alliance Access, if users share a common UNIX or Linux password, it is important
that all Alliance Access users are notified when this shared password is updated.

27 March 2015 23
Alliance Access 7.1 on Alliance Web Platform

3.6.3 AIX, Linux, or Solaris File System


Introduction
UNIX or Linux is a file-oriented operating system. Every program, directory, data file, and device
(such as terminal, communications interface, or printer) is represented by a file.
Each file has a number of attributes associated with it, including:

File Ownership: every file is owned by a known user

Group Ownership: users may belong to user-definable groups. The group ownership of a file
determines which group that file is associated with (allowing members of that group a defined
level of access to that file).

File Permissions: these determine who has:

Read access (that read that file)

Write access (that update and modify that file)

Execute access (that run that file, assuming that the contents are executable)

Each of the above is set independently for:

the owner of the file

the members of the group which owns that file

the rest of the world (meaning all other users of that system, including connected
systems)
The attributes are maintained for all files in the system and are stored with each file. Read,
write, or execute access is denied to a user that does not possess the correct level of
privilege, as defined by the file attributes. File permissions may be modified, at any time, by
the owner of that file or by the UNIX or Linux system administrator.
All Alliance Access program and data files are owned by the Alliance system administrator
and accessible, with restrictions, only by members of the ALLIANCE group of users.
The saa_system integrity command can be used at any time to verify the correct setting of
Alliance Access file attributes. For more information, see the Administration Guide for your
AIX, Linux, or Oracle Solaris operating system.

3.6.3.1 File Access Controls

Controls
The UNIX or Linux operating system provides basic security mechanisms to ensure that files
may be read, updated, or run only by those users that have been granted the correct UNIX or
Linux-level privileges. Groups of users may share the same privileges.
These privileges may be granted separately to:

the owner of that file

other members of that same group

all users
The Alliance installation process ensures that all Alliance users belong to the group ALLIANCE.
All executable files are owned by the Alliance Administrator.

24 Security Guide
Security Aspects to Consider

In this way, no user - other than the Alliance System Administrator - has direct access (for
example, using normal UNIX or Linux commands) to Alliance programs and files.
To ensure that the file protection mechanisms remain unaltered, checks are made at various
times on UNIX or Linux file permissions, as described in the following sections.

3.6.3.2 Security Check

Checks
A full integrity check of all executable files (as performed during the installation process) may be
performed at any time during the life of an installation.
If the integrity of Alliance software is ever in doubt (or periodically as a precautionary measure)
then the Alliance System Administrator may run a dedicated script which performs the following
functions:

the full CRC values - for each executable file - are re-calculated and checked against the
trusted values stored in the Alliance database. Any discrepancies are reported on-screen (not
in the Event Log).

the file permissions of all Alliance software files are checked against the trusted values stored
in the Alliance database. Any discrepancies are reported on-screen.

3.6.4 AIX, Linux, or Solaris Software and Data Integrity


3.6.4.1 Software Backup

Terminology and overview


The software is the release tree of the programs used to handle data in the database. Software
is always defined by the Name, Release, and Patch level.
Software backups provide protection against software corruption.
Consider the worst-case scenario in which your system crashes, software files are corrupted,
but your backup is not available, meaning:

Situation Action required

No Alliance Access software is The entire Alliance Access software must be reinstalled.
available.

No Alliance Access patches are The latest mandatory patch and possible optional patches must be
installed. reinstalled.

The database backup is It is not possible to restore the database backup on another machine
useless. without a previous restore of an adequate software backup.

Best practice
Keep a software backup on external media or at least on a different disk. It is highly
recommended to make a software backup before any sensitive action, such as a software
upgrade.

27 March 2015 25
Alliance Access 7.1 on Alliance Web Platform

Limitations and known problems


The Alliance Access server and workstations must be on the same Release and Patch level,
except when explicitly specified differently in the Release Letter.
For more information about the release and patches of operating systems for Alliance Access,
see the OS Levels and Patches Baseline document.

3.6.4.2 Use of Dual Disks

Dual disks
Alliance supports the use of dual disks - systems using two disk drives to segregate data
storage and to improve disk performance. For example, Alliance software and the database
may be stored on one disk, while the backups of message and event archives may be stored on
the other.
If a reliable backup regime is used, following a single-disk failure then the complete Alliance
Interface may be recovered from the files stored on the remaining disk and from software and
data backups.

3.6.4.3 Dual Hardware Configurations

Dual hardware
Dual hardware configurations provide a high level of protection against most types of hardware
failure.
Systems may be configured in pairs, sharing X-Terminal connections over a common LAN, and
sharing dual disk resources between the two systems. In such configurations, one processor
acts as the live machine and performs all processing functions. The other machine acts as a
standby. In the event that one machine (or a part of that machine) fails, external connections
(for example, to the SWIFTNet) only have to be swapped to the other machine for processing to
be restarted with minimal disruption to operations.
The Installation Guide for AIX, Oracle Solaris, or Windows provides a detailed description of the
dual hardware configurations supported for Alliance.

Note This facility is not supported on certain operating systems, such as Linux.

3.6.4.4 HACMP - High Availability Cluster Multi-Processing (AIX only)

Introduction
This solution consists of two nodes running in a cluster. In case of first node failure, the HACMP
starts the second node, where Alliance will start after the database recovery.
For more information, see the IBM PowerHA SystemMirror Standard Edition 7.1 Installation and
User Guide.

26 Security Guide
Security Aspects to Consider

3.6.5 AIX, Linux, or Solaris-Related Security Weaknesses


Introduction
Historically, UNIX or Linux systems possess a number of shortcomings with regard to system
security - either directly or indirectly:

UNIX or Linux systems are typically administered by a single system administrator who take
sole charge of the system and its resources.

UNIX or Linux systems are widely available - including the source code for many routines.
This allows weaknesses to be exploited by those seeking to take advantage of such systems.

UNIX or Linux systems are becoming less and less expensive. The cost of full-time expert
UNIX or Linux system administrators becomes relatively high and is, therefore, often
overlooked.

UNIX or Linux systems are powerful and offer lots of different utilities. This makes UNIX or
Linux systems complex (with literally thousands of files) and relatively difficult to administer.

UNIX or Linux systems are flexible and it is possible to set up a system in many different
ways, some of which are inherently insecure.

UNIX or Linux programs are portable and many are granted too high a level of privilege, just
to make them work. Some implementations suffer from translation bugs with significant
security consequences.

UNIX or Linux offers many networking possibilities for distributed processing and for remote
access. Security threats tend to multiply with networking, or the network itself becomes a
security threat.
Some of these concerns do not apply to Alliance Access when running as the only application
on a stand-alone system. However, the level of concern increases when other applications are
run on the same system, and when the Alliance Interface runs on distributed networks.
While SWIFT has confidence in the Alliance Interface and in the UNIX-based or Linux-based
systems on which it is implemented, SWIFT clearly cannot be responsible for the use of bad
security procedures by persons with an inadequate level of knowledge or skill.

3.6.5.1 Root Privileges

Root identity
Every UNIX or Linux system has a UNIX or Linux system administrator that, from time to time,
must act with "superuser" or "root" privileges to perform administrative tasks at the operating
system level. When acting in this way (that is when logged on as "root") security checks - such
as the restrictions imposed by file ownership and access permissions - are ignored (although
some systems can log all root activity).
When using the root identity, all of the following actions are possible by the UNIX or Linux
system administrator:

add, remove, or change user accounts

read, delete, or modify any file in the system

run any program

kill any process which is running

27 March 2015 27
Alliance Access 7.1 on Alliance Web Platform

shut down the system

mount and unmount file systems

enable or disable audit facilities

become any other UNIX or Linux user on the system

reconfigure network devices and LAN connections

alter the limits set for CPU time, data segment size, core file size, and so on

turn accounting on and off

access any device on the system (printer, terminal, modem, and so on)

set (or reset) the date and time

change the priority of a process

Protection
Clearly, persons acting as root are able to take complete and sole charge of a system. There is
no ability to exercise dual control over root privileges. The only real protection against others
using the root account is by means of the password assigned to the root account. This
password must be protected at all times and NEVER disclosed to others.
Most system break-in attempts are designed to acquire root privileges. When this is achieved,
an intruder can do almost anything inside the system.
The UNIX or Linux command "su" (substitute user) can be used to acquire temporarily the
identity of another user. Doing so prompts for the password of the account to which you are
changing. Intruders may guess at the root password, so it is important to select a very strong
password for the root account. Most systems log bad su attempts, identifying the users that tried
to acquire another's identity. A similar facility allows processes to be made to run with root
privilege.
The existence of the root account represents, for some, the most serious security weakness in
UNIX or Linux systems. However, by adopting the following procedures, this weakness can, at
least, be minimised:

give careful consideration as to who must be appointed to the role of the UNIX or Linux
system administrator (and therefore act with root privileges)

provide adequate system and security awareness training to the UNIX or Linux system
administrator to provide that person with the skills necessary for this important task

limit direct access to the root account. Ensure that the UNIX or Linux system administrator
also has a normal UNIX or Linux user account, within which much of the administrator's work
can be performed. When necessary, the administrator may then su to the root account to
perform privileged tasks

ensure that special consideration is given to the choice of password for the root account. If
the root account password is compromised, then the whole system is compromised

to enable emergency access to the system with root privilege, this password can be recorded
by the UNIX or Linux system administrator in two parts, and each part safe-stored and made
available to another user (with suitable skills) for emergency use

28 Security Guide
Security Aspects to Consider

3.6.5.2 Client/Server Communications

Client and server processes


The architecture of the Alliance Interface is built around the concepts of client and server
processes, where client processes request services from servers and server processes provide
services to clients.
To authenticate the communications between clients and servers (and to ensure that no rogue
processes have been introduced), Alliance Access uses a security block in all Remote
Procedure Call (RPC) communications. This enables file ownership and permissions, operator
identities, process IDs, and so on to be verified at each RPC. The full format of this security
block is not published outside of SWIFT, and the code used to create and verify the security
block is highly complex.
For more information about RPC, refer to the Installation Guide for AIX, Linux, or Oracle Solaris.

3.6.5.3 Use of LANs

Local Area Networks


The use of Local Area Networks (LANs) enable remote terminals to connect to host systems
and different hosts to be connected together to form networks. Various protocols (for example,
X-Windows to connect X-Terminals, or Ethernet and TCP/IP for network communications)
enable discrete connected systems to operate as one logical system.
LANs are used to carry the necessary commands and data between display manager and
terminal, between client and server and between connected hosts.
A possible weakness exists in that data, considered critical on one system, may be sent to
another system, or terminal, through a connecting LAN, in clear. This can allow someone, able
to monitor LAN traffic, to gain access to secret data. For example:

user names and passwords, entered at a remote terminal, are sent over the connecting LAN
in clear, for verification by the host system to which that terminal is trying to log on

Alliance Access encrypts data at the database layer using server processes dedicated to the
reading and writing of encrypted data. A remote client, requiring the use of some encrypted
data, will receive that data over the LAN only after it has been read and decrypted by the
database server - that is in clear.

3.6.5.4 Use of X-Terminals

X-Terminal
The X-Windows environment (commonly known as X11) provides a flexible means whereby
humans can interact with computer processes in a meaningful way - such as through a
graphical user interface.
Traditionally, if a computer process must display information to a user, it had to know at which
terminal the user can be located. With X-Windows, each host on a system runs an X11 windows
manager, which takes care of the sending and receiving information between user terminals and
the processes running at that host.
At the terminal level, each runs an X-Terminal protocol allowing users to log on to one or more
hosts from the same screen, and relying on the X-Terminal protocol to manage the
communications with the X-Windows managers of those hosts. Separate physical windows may
be displayed on a user's screen, each communicating with a specific host.

27 March 2015 29
Alliance Access 7.1 on Alliance Web Platform

In a networked environment, with many hosts, perhaps running distributed processes, X-


Windows ensures that keyboard and mouse input is directed to the correct remote process, at
the correct host. Similarly, output from processes running on hosts anywhere in the network is
routed, by the X-Windows manager at that host, to the correct terminal.
In practical terms, this means that, when properly configured, a user may log on to a host (which
need only be identified by name), run programs, manipulate data files and so on, without
needing to know the physical location of that host.
X-Terminal emulation programs are common on many small desktop computers, such as PCs.
This enables, for example, a PC to be used as an X-Terminal for much larger and more
powerful UNIX or Linux systems. LANs are used to connect X-Terminals into the network.
X-Windows implements the true meaning of the server concept. Your display can serve clients
on any system and, conversely, clients running on your system can display their output on any
other screen.
However, from the security point of view, the scope for abuse is considerable. The design of X-
Windows allows any client that successfully connects to your local X server to take complete
control of your display (and allows your local clients to do the same to others).
Two methods of controlling X-Windows access are possible:

Host-Based Access Control: Host-based access control uses a file which contains a list of the
hosts (by name) that are allowed to send clients to display on your terminal. This list,
normally configured by the UNIX or Linux system administrator, is read at startup. However,
this scheme suffers from two major restrictions which make it inadequate for real security:

You cannot run client processes, for display at your terminal, from those hosts who do not
have access to your display. You therefore have to deny yourself access, to deny it to
others.

This control mechanism is easily bypassed. Any user with an account on your machine (or
any other host your server allows access to) may access your display.

User-Based Access Control: With this scheme, when a user logs on, a secret code is written
to a file in the user's home directory, by the display manager. This code is also made
available to the local X-server. Once this code is established for an X-session, any client
wanting to access the user's display, must first present the correct code before it is allowed
access to the server.

This scheme relies on the fact that UNIX or Linux processes, started by a particular user,
inherit that user's file attributes. The file containing the secret code can only, therefore, be
read by the owning user, or by processes started by that user. This method is only as secure
as the user's account and, therefore, the user's password. Not all versions of X-Terminal
support user-based access controls.

3.7 Security on Windows Systems


Overview
This section describes security considerations when running Alliance Access on a Windows
operating system.

30 Security Guide
Security Aspects to Consider

3.7.1 Windows User Accounts


Overview
The system administrator is responsible for setting up a Windows user account for each Alliance
operator. A user account contains a list of groups to which the user belongs. Membership of a
group gives the user the right to perform various tasks within Windows. For example, members
of the Administrators group have the right to fully administer the computer or domain.
The administrator may have to set up a user group specifically for the Alliance users to ensure
that other Windows users do not have access to the Alliance software.

Note Alliance users that are enabled to start and stop the Alliance server must have an
administrator account.

An Alliance operator must be a member of either the Administrators group or the group which
has rights to use Alliance.

3.7.1.1 Built-In Accounts

Description
Windows has two built-in accounts, Administrator and Guest. When Windows is first installed,
Guest has no password and its account is enabled. It is recommended that Guest must be
disabled, renamed, and assigned a password. Administrator must also be renamed and
assigned a password.
For information about modifying the built-in accounts, see the Microsoft Windows
documentation on User Manager.

3.7.1.1.1 File Protection

Permissions
All the directories and files in an NTFS partition have permissions associated with their use. The
default permission in Windows is "Full Control".
For a directory, Full Control allows:

viewing file names and sub-directory names

changing to the directory's sub-directories

viewing data in files and running application files

adding files and sub-directories to the directory

changing data in files

deleting the directory and its files

changing permissions on the directory and its files

taking ownership of the directory and its files.


For a file, Full Control allows:

viewing the file's data

running the file if it is a program file

27 March 2015 31
Alliance Access 7.1 on Alliance Web Platform

changing data in the file

deleting the file

changing permissions on the file

taking ownership of the file.


Alliance does not set any file permissions during installation, so Full Control is applied to all
software and data. It is recommended that access to software and data is restricted to the users
that need it. Restricting file permissions protects data against unauthorised use. Executable files
must be set to read-only and restricted to users authorised to run them.
For information about how to manually change permissions, see the Microsoft Windows
documentation on Windows Explorer and User Manager.

3.7.1.1.2 Auditing Files and Directories

Overview
Auditing files and directories allows you to track their usage. For a particular file or directory, you
can specify which groups or users and which actions to audit. You can audit both successful
and failed actions. Windows stores the information generated from auditing in a file. For
example, auditing can be set to monitor attempts to modify protected files. Be careful to limit the
actions that you audit. If you audit too many actions, then the performance of your system may
be affected.
For information about activating auditing, see the Microsoft Windows documentation on
Windows Explorer.

3.7.2 Windows Passwords


Overview
Windows users must specify their user names and passwords each time they log on to
Windows.
The system administrator is responsible for the initial definition of user names and passwords.
These are either defined during the installation of Windows or later on with User Manager.
Details of the user name and password are then passed to the user they have been created for.
From then on, the user is responsible for keeping a password secret and renewing it when
required.

Restriction Description

Maximum Password Age The length of time a user's password is valid before they are forced
to change it.

Minimum Password Age The minimum length of time a password must be used for before it
can be changed.

Minimum Password Length The minimum length of a password.

Password Uniqueness The number of new passwords that are used by a user account
before an old password can be reused.

These restrictions are part of the Account Policy of each user account. There are also the
following user properties:

32 Security Guide
Security Aspects to Consider

Property Description

User Must Change Password at Forces a user to change the password at the next logon. This is a
Next Logon way of ensuring that a user becomes responsible for his or her
password.

User Cannot Change Password This option is usually applied only to user accounts used by more
than one person.

Password Never Expires Prevents the password from expiring, overriding the Maximum
Password Age setting in the Account Policy.

Users are forced to change passwords in the way defined in the user's account. If users think
that someone else knows their password, then they must change it.

3.7.2.1 Screen Savers

Overview
A password-protected screen saver ensures that unauthorised users cannot access a computer
that has been left unattended. Windows has a password-protected screen saver. If someone
tries to access Windows when this screen saver is on, then a Lock Workstation dialog box
appears. To unlock the workstation, the user's password must be entered.

3.7.3 Windows File System


Overview
Alliance must be installed in a Windows file system (NTFS) partition. NTFS has useful directory
security features which let you define file and directory permissions and define the ownership of
files.
When resources are shared in the NTFS environment, remote access is limited by a
combination of two sets of permissions:

network sharing permissions

local NTFS permissions.


Alliance Workstation users do not have permission to share directories on the server. They are
able to update the Alliance database because of the entitlements, and permissions given to
them in their operator definition.
Alliance Workstation does not store any data in the local NTFS partition.

3.8 Alliance Access Operating Modes


Description
Alliance Access can operate in either of two modes:

Operational mode is the normal multi-user mode of operation. In this mode, all defined
Alliance Access operators may sign on and make use of Alliance Access facilities.

Housekeeping mode is selected whenever system maintenance tasks have to be performed.


In this mode, by default only one user at a time is allowed to sign on to Alliance Access.
Security officers can change the number of operators permitted to sign on in housekeeping
mode.

27 March 2015 33
Alliance Access 7.1 on Alliance Web Platform

In housekeeping mode, queues are frozen and messages cannot be sent or received. No
scheduled processes take place when the servers are running in housekeeping mode.
Note the following additional restrictions on the use of housekeeping mode:

Gateway connections are not visible when the servers are running in housekeeping mode.

You cannot activate or deactivate a correspondent when the servers are running in
housekeeping mode

You cannot add or delete countries or currencies when the servers are running in
housekeeping mode.
Additionally, certain system changes can only be made if Alliance Access is in housekeeping
mode (when only a single user can sign on). The system must be stopped and restarted to
switch between the normal operational mode (when all users can sign on) and housekeeping
mode. Backups can be done in both housekeeping and operational mode.
Following are examples of tasks that must be performed in housekeeping mode:

installing a new message syntax table

creating and configuring logical terminals

installing value-added services, such as FINCopy

managing the FINCopy Profiles

installing the Alliance Bank File

managing the MX message standards

assigning routing keywords

modifying active routing rules


The Stop Alliance and Restart Alliance commands in the System Management entity are
used to stop and restart Alliance Access in a different operating mode. A restart causes Alliance
Access to halt its current operation and shut down, before restarting in the selected operating
mode.
When Alliance Access is stopped, any user currently signed on to Alliance Access is warned. A
short period of time is allowed for all current users to sign off (after which their current sessions
are aborted).
If a calendar has been created, then Alliance Access can be scheduled to stop or restart
automatically at specific times on specific days.
The entitlement to stop and restart Alliance Access is provided to security officers, system
administrators and Supervisors, and may also be assigned to an operator as part of an operator
profile. For more information about the default profiles, see "Default Operator Profiles" on page
84.

34 Security Guide
Security Aspects to Consider

3.9 Offline Maintenance Utilities


Overview
A number of facilities are provided in Alliance Access for exclusive use by the System
Administrator for off-line maintenance of Alliance Access. These facilities are provided by
means of the System Administration application and the Installation application. Only users set
up as members of the administrators group can access these applications.
The use of these facilities is summarised in this section, and detailed in the Administration
Guide for AIX, Linux, Oracle Solaris, or Windows.

Configuration
On Windows:
On Windows servers, the Installation application includes facilities that allow the system
administrator to:

change information about the Alliance Access server

display version information

produce a detailed system configuration report which includes hardware and software
information.
The System Administration application includes a facility to configure archive directories and
message partners.
On UNIX or Linux:
The System Administration application provides commands to manage the system and make
configuration changes.

Instance management (UNIX or Linux only)


The System Administration application provides functions to display and rename Alliance
instances installed on the system.

Start/Stop Alliance servers


The System Administration application provides facilities for the Alliance System Administrator
to start the Alliance Access servers and to shut down the servers in an orderly fashion. The
Alliance Access servers may also be shut down (or restarted) from within the System
Management entity through the use of the Stop Alliance and Restart Alliance commands.

Backup and restore facilities


Facilities are provided within the System Administration application (on Windows only) and
through command line tools to create offline backups of the Alliance Access database - and
later restore these backups if a recovery is required.
These facilities must only be used in exceptional circumstances, but must be fully tested and
proven for each new installation as part of the normal operational readiness testing (that is,
before live operations begin).
Unless the database recovery mode is activated (which requires licence option 14:DATABASE
RECOVERY), the messages and Event Log (that is, those not yet archived) are never backed
up and hence, never restored. This is to avoid the risk of duplication. For more information
about the database recovery mode, see the Administration Guide for AIX, Linux, Oracle Solaris,

27 March 2015 35
Alliance Access 7.1 on Alliance Web Platform

or Windows or www.swift.com > Connectivity > Alliance Access Database Recovery Information
Paper.

Software security check


All executable files (that is, programs, shared libraries and scripts) on the Alliance Access
release DVD are authenticated by SWIFT. A list of all valid authentication codes is also included
on the release DVD and stored (in an enciphered form) with each Alliance installation.
The saa_system command line tool enables the Alliance System Administrator to verify that no
executable files currently installed have been changed or tampered with. Any discrepancies are
reported (on-screen) whenever this tool is run. For more information about this tool, see the
Administration Guide for AIX, Linux, Oracle Solaris, or Windows.
A software security check is also performed online every time an executable file is run. The file
in question is verified before it is run, and is not run if a discrepancy is found.

Use of bank query


The saa_bankquery tool provides access to the dedicated Alliance Access database enquiry
and repair facility. The tool is used to verify and repair database entities. Only the Alliance
Administrator can run this tool.
Given the powerful nature of this tool, its use is protected by three different passwords:

the first password is the operating system password of the Alliance Administrator (initially
required to log on to the Alliance Administrator account to run saa_bankquery)

the second password is that of any Alliance operator (for example, a supervisor) who has
been granted the specific entitlement, within Alliance Access, to run saa_bankquery

the third password is a dedicated password that must be obtained from Support, as
described further.
When running the saa_bankquery tool for repair, the Alliance Access servers must not be
running.
All access to bank query is logged on the Event Log. Any updates or modifications to Alliance
Access data is also logged.
For more information about the use of the saa_bankquery tool, see the Administration Guide
for AIX, Linux, Oracle Solaris, or Windows.

Note An operator using One-Time Passwords cannot use the saa_bankquery tool.

Use of journal query


The System Administration application provides a facility that allows users to query and use the
Event Log entity, without having to sign on to Alliance Access. Journal Query may also be used
for diagnostic purposes if either the System Administration application or the Alliance user
interface is unavailable or cannot be started.

36 Security Guide
Installation, Upgrade, and Licensing

4 Installation, Upgrade, and Licensing


Introduction
Alliance Access provides a number of controls to ensure that only genuine users can gain
access to it. This section describes the use of account names and passwords - at both the
operating system level and the Alliance Access level - and shows how the security officers
control access to the Alliance Access software.
Before Alliance Access is installed, the security officers, or the technical engineers, should
determine what changes are needed to the default settings, such as configuration and security
parameters. In addition, they should determine what level of security to implement to secure the
system, as well as the user access to the software.

4.1 What Is Secure Channel?


Overview
Secure Channel is an online application for SWIFTNet Security Officers and Alliance Security
Officers. It enables registered SWIFTNet Security Officers to:

submit SWIFTNet offline interventions

register new, or de-register obsolete SWIFTNet Security Officers

update their own address details

manage the PKI delegation and the authorisation setting

recertify SWIFTNet Security Officer profiles


Secure Channel also allows registered Alliance security officers to view SWIFT Interface
software licence keys online.

How to Access Secure Channel


To acquire access to the Secure Channel application, you must first be a registered user for the
online services on www.swift.com. A swift.com administrator in your institution must approve
your registration request before you can use the online services.
On www.swift.com, go to Support > Secure Channel > Access Secure Channel.

4.2 Alliance Initialisation Password


Overview
The use of the Alliance Initialisation Password provides a mechanism whereby the legal rights
to the use of Alliance Access software with the purchased options (by the relevant destinations
and with the relevant message types) may be passed from SWIFT to the purchasing
organisation in a reliable and controlled manner.
The two parts of the password are each 16 alphanumeric characters in length:

Part 1 is addressed to the left security officer.

Part 2 is addressed to the right security officer.

27 March 2015 37
Alliance Access 7.1 on Alliance Web Platform

The Initialisation Password is calculated using a proprietary algorithm together with a hard-
coded enciphering key, known only to SWIFT.
The Alliance Initialisation Password is uniquely calculated for each combination of:

Alliance Access software release

the software options purchased

the identity of the licensed SWIFT destinations

the SWIFT message types used at those destinations

How to obtain
To obtain passwords, use Secure Channel. For more information, see http://www.swift.com/
support/secure_channel.page?.

When to use
Both parts of the Initialisation Password must be entered during the installation of the Alliance
Access software release (or upgrade), enabling dual control to be exercised over software
installation. Without both parts of the Initialisation Password, Alliance Access cannot be
installed.
During software installation, the Initialisation Password is recalculated using the information
entered during installation. The calculated Initialisation Password must match that entered by
the security officers for the software installation to proceed further.

4.3 Alliance Master Password


Overview
The Alliance Master Password is calculated by SWIFT at the same time as the Initialisation
Password and is based on the same combination of data, but using a different hard-coded key.
This password is also in two parts (each part consisting of eight alphanumeric characters), and
is distributed along with the Initialisation Password. Part 1 is dispatched to the left security
officer of the purchasing organisation along with the relevant part of the Initialisation Password.
Part 2 is addressed to the right security officer at the same organisation.
During installation, the Master Password is recalculated using the licensing data and stored in
encrypted form. Also during installation, two operator definitions, LSO and RSO, are created.
LSO and RSO allow the two security officers to sign on and use Alliance Access after
installation. To sign on, the security officers use Parts 1 and 2 of the Master Password. The
Master Password entered by the security officers is verified against the stored version.

Password Control
When the security officers sign on for the first time, they are forced to change their part of the
Master Password.

Note Each security officer must first update their part of the Master Password before
either security officer attempts to use any other facilities. The Master Password can
be changed to any combination of characters, but must be a minimum of four
characters in length and a maximum of 30.

The current Master Password is one of the inputs used to create system-generated passwords
in Alliance Access. Therefore, whenever the Master Password is updated, all operator
passwords that include a system-generated element, must also be renewed.

38 Security Guide
Installation, Upgrade, and Licensing

After initial sign-on, the secrecy of the Master Password is the joint responsibility of the left
security officer and the right security officer. The Master Password is the most important
password in Alliance Access. If a security officer (left security officer or right security officer)
forgets a password, then it is possible under certain conditions to reset the security officer's
password to the original Master Password supplied by SWIFT. It is therefore important that the
original Master Password is retained and stored in a secure place under the control of both
security officers. For more information, see "Resetting a Master Password" on page 39.

Logging In
See the Alliance Access Configuration Guide for the specific steps to log in, change your
password, and log out. In the same document are detailed instructions on how to use the
Alliance Access graphical user interface (GUI).

4.3.1 Resetting a Master Password


Password conditions
If a security officer (left security officer and right security officer) forgets a Master Password,
then the password can only be reset if both the following conditions are met:

the other security officer resets the password - an operator with Approve Operator
entitlement cannot do so

the Password: Reset Peer Officer Pwd parameter is already set to Yes.
For example, if the above conditions are met, then the left security officer can use the
Reset RSO Pwd command in the Security Definition entity to reset the right security officer
password. The password is reset to the eight alphanumeric character Master Password that
SWIFT dispatched to the right security officer at the most recent Alliance Access licensing.
On installation, the Password: Reset Peer Officer Pwd parameter is set to No, which
means that the security officers cannot reset each other's password. The security officers can
use the Security Definition entity to change the value of this and other security parameters.
If the Password: Reset Peer Officer Pwd parameter is set to No, and a security officer
forgets a password, then the institution's local Support Centre must be contacted for further
instructions.

4.4 Sign-on Time Limits


Restricting access times
Alliance enables security officers to restrict the time of day during which any particular operator
may sign on. This feature prevents an operator from being able to sign on outside normal
working hours, for example.
Each day of 24 hours is split into two distinct time periods. As a part of that operator's profile, a
security officer may define the start and end times for each of the two periods, during which a
sign-on by that operator is allowed. Any attempt by that operator to sign on to Alliance outside
of these defined periods, is rejected. Only sign-on attempts are monitored - once signed on, an
operator may use Alliance as long as required (or until the system is shut down). Initially, there
is no restriction as to when any operator can sign on. Both security officers must approve any
changes to this parameter.

27 March 2015 39
Alliance Access 7.1 on Alliance Web Platform

Warning When an operator signs on from the Alliance Web Platform GUI, Alliance compares
the defined sign-on period for the operator with the system time of the system from
which the browser was launched. If the system time is within the operator's sign-on
period, then the operator can sign on. Therefore, an operator who can change the
Windows time (or time zone) of the system from which the browser was launched
can potentially bypass the sign-on period.

Automatic disabling after period of inactivity


Alliance enables security officers to define the number of days during which an enabled
operator must sign on. If the operator fails to do so, then the operator is automatically disabled.
This feature prevents an operator from being able to sign on after an extended period of
absence.
The security parameter System: Disable Period, which is available to the security officers
from the Security Definition application, can be set to any value between 0 and 999.
When set to 0, no validation is performed, and operators are not automatically disabled.
When set to a value other than 0, Alliance validates each operator (at midnight). If the value is
greater than the number of days since the operator last signed on (or was enabled), then the
operator is disabled. The same validation is performed each time the Alliance Access servers
are started.

Note An operator's password being reset does not affect this validation.
The LSO and RSO operators cannot be automatically disabled.

40 Security Guide
Configuration and Security Parameters

5 Configuration and Security Parameters

5.1 Classes of Configuration Parameters


Overview
Alliance Access contains a number of system parameters that you can configure. You can
change the values of these parameters only if the permissions of your operator profile permit
you to change them.
Configuration parameters are grouped by class.

Note Some parameters described in this section are only available if you have licensed
the relevant option for your system.

IPLA configuration parameters


In addition to the classes listed here, configuration parameters resulting from installing
components for IPLA may also appear. The bundle symbolic name appears as the value for
Class. The value for Component is IPLA.

5.1.1 Activation
List of activation parameters

Parameter Description

Start evaluation Enter an activation code, which SWIFT has


provided, to start the evaluation period for
Operational Reporting. This will activate
Operational Reporting, which will copy all
messages to the Reporting data store. Depending
on the number of messages in the database, this
operation could take a considerable amount of
time.

Activate reporting To activate Operational Reporting, set this


parameter to Activate. This will copy all
messages to the Reporting data store. Depending
on the number of messages in the database, this
operation could take a considerable amount of
time.
To deactivate Operational Reporting, set this
parameter to Deactivate. This operation will
remove all message data from the Reporting data
store.

27 March 2015 41
Alliance Access 7.1 on Alliance Web Platform

5.1.2 Alarm
List of alarm parameters

Parameter Description

Maximum The maximum number of alarms that can be displayed on Alliance Workstation
simultaneously:

Default: 3

Minimum: 1

Maximum:20
Changes to this parameter take effect at the next login to Alliance Workstation.

Timeout The number of minutes an alarm popup remains on screen:

Default: 15

Minimum: 1

Maximum:120
Changes to this parameter take effect at the next login to Alliance Workstation.

Note Alliance Access on Linux does not support Alliance Workstation.

5.1.3 Alarm Message


List of alarm message parameters

Parameter Description

Sender LT Specifies the logical terminal (BIC12: LT followed by XXX) that is used to send
alarm messages to Internal Correspondents.
Changes to this parameter take effect at the next Alarm Message/Frequency
check.

Frequency Alarm Message/Frequency check (in minutes). Default value: 5.


Changes to this parameter take effect at the next Alarm Message/Frequency
check.

5.1.4 Backup
List of backup parameters

Parameter Description

Archive Backup The Oracle database requires this parameter to create the Data Pump files
Dir Object containing the backups of archives.
Maximum value: 30.
Changes to this parameter take effect at the next backup or restore operation.
This parameter is only available when the Alliance Access database is hosted.

42 Security Guide
Configuration and Security Parameters

Parameter Description

DB Backup Dir The Oracle database requires this parameter to create the Data Pump files
Object containing the backups of the Alliance Access database.
Maximum value: 30.
Changes to this parameter take effect at the next backup or restore operation.
This parameter is only available when the Alliance Access database is hosted.

Location This parameter defines the file directory wherein the Alliance Access backups are
Backups created. This directory must be shared between the Alliance Access host and the
database host. If the parameter has no value, then no backup or restore can take
place.
The parameter has no value by default.
Changes to this parameter take effect at the next backup or restore operation.
This parameter is only available when the Alliance Access database is hosted.

Location This parameter defines the file directory remotely accessed from the database host
Backups DB Host wherein the Alliance Access backups are created. If this parameter has no value,
then the value specified for the Location Backups parameter is used.
The parameter has no value by default.
Changes to this parameter take effect at the next backup or restore operation.
This parameter is only available when the Alliance Access database is hosted.

5.1.5 Batch Input


List of batch input parameters

Parameter Description

Automatic - Automatic Input Backup Directory.


Backup Dir All files in this directory that are older than the Batch Input History Period are
deleted.
Default: C:\Alliance\Access\usrdata\FTA\back
Changes to this parameter take place at the next poll.

Automatic - Specifies whether the status of a message partner is set automatically to Disabled
Disabling if the message partner receives an invalid batch file.
Possible values are Yes and No.
Default: Yes
Changes to this parameter take effect the next time the MXS component is started.
This parameter has an effect on File Transfer message partners only.

Automatic - Error Automatic Input Error Directory.


Dir All files in this directory that are older than the Batch Input History Period are
deleted.
Default: C:\Alliance\Access\usrdata\FTA\error
Changes to this parameter take place at the next poll.

Automatic - The Session Autostarter Polling Timer in seconds. Default value: 60.
Polling Timer Changes to this parameter take place at the next poll.

History Period The number of days to keep history records for batch duplication check and to
keep the files in the file transfer adapter backup and error directories. Default
value: 10.
Changes to this parameter take place at the next poll.

Log Directory The location where report files generated for XML version 2 (MT/MX) input are
stored.

27 March 2015 43
Alliance Access 7.1 on Alliance Web Platform

5.1.6 Batch Output


List of batch output parameters

Parameter Description

Include payload Specifies whether or not the payload (full) path must be automatically added to the
in LTA LTA command parameters by Alliance Access, for File messages sent over a File
Transfer Message Partner.
If this parameter is on and the message partner Maximum number of messages
per session is set to 1, then Alliance Access automatically adds the payload full
path as the last parameter of the LTA command (after the XML file) for File
messages.
If this parameter is on and the message partner Maximum number of messages
per session is greater than 1, then Alliance Access automatically adds the path to
the payload location as the last parameter of the LTA command (after the XML
file).

LTA Timeout Defines the Local Transfer Agent completion time in minutes. This is the time that
Alliance allows for the Local Transfer Agent to process a batch output file. If the
Local Transfer Agent has not finished its task within this time, then an event is
written to the event log. Default value: 5.

LTA waiting Specifies whether Alliance can wait for Local Transfer Agent completion before
mode closing the session. Default value: Off.

5.1.7 Database
List of database parameters
This parameter is not available when the licence package 13:HOSTED DATABASE is present.

Parameter Description

Location Location of the daily Messages database files. Changes to this parameter take
Messages effect when the next database file is created.
Note: if the user enters an invalid path or if the server processes have no write
access to the specified location, then the new database files are created in the
following directory:

On UNIX or Linux: $ALLIANCE/database/datafiles/MESG

On Windows: %ALLIANCE%\database\datafiles\MESG

Location Journal Location of the daily Journal Events database files. Changes to this parameter take
Events effect when the next database file is created.
Note: if the user enters an invalid path or if the server processes have no write
access to the specified location, then the new database files are created in the
following directory:

On UNIX or Linux: $ALLIANCE/database/datafiles/JRNL

On Windows: %ALLIANCE%\database\datafiles\JRNL

44 Security Guide
Configuration and Security Parameters

5.1.8 Alliance Developers Kit


List of Alliance Developers Kit parameters

Parameter Description

ADK Storage This parameter defines the directory in which Alliance Developers Kit applications
can store their specific information. The contents of this directory are considered
during the backup and restore operations.
The default path for this directory is as follows:

On Windows: %ALLIANCE%\data\ADK_DIR

On UNIX or Linux: $ALLIANCE/data/ADK_DIR

Operational Trace When this parameter has a value On, a journal entry is written for every call that is
made to an Alliance Developers Kit (Toolkit) function. The journal entry describes
in full the call made by the Alliance Developers Kit function. Default value: Off.
You must restart an application in the Alliance Developers Kit, to apply the changes
to this parameter.

5.1.9 Disk Space


List of disk space parameters

Parameter Description

Frequency The interval in seconds (in multiples of 60) at which disk space is checked.
Default value: 300. Minimum: 120. Maximum: 3600.
Change to this parameter take effect at the next disk-space check.
A warning will be given if free disk space drops below a Warning parameter.
Repeat warnings are given at 10 times the interval.

Recovery Alliance Access shuts down when the free space of the Recovery Backup Disk
Shutdown - MB becomes less than this number of megabytes. If the value is 0, then no action is
taken.
Default value: 1000. Minimum: 0. Maximum: 4190000.
This parameter is available when 14:DATABASE RECOVERY is licensed.

Recovery Alliance Access issues a warning when the free space of the Recovery Backup
Warning - MB Disk becomes less than this number of megabytes. If the value is 0, then no action
is taken.
Default value: 5000. Minimum: 0. Maximum: 4190000.
This parameter is available when 14:DATABASE RECOVERY is licensed.

Shutdown - MB Sets the absolute minimum free disk space (in MB) that must be available on the
file systems hosting the database. If the free disk space available for one of these
file systems falls below this value, then Alliance Access shuts down.
Default value: 1000, to which the system automatically adds (for recovery
purposes) the size of the largest database file stored in the database, plus the size
of the database index file. Minimum: 0. Maximum: 4190000.
The frequency at which this parameter is checked is set using the Disk Space -
Frequency parameter.
You must restart Alliance Access, to apply the changes to this parameter.

Shutdown - Shutdown Alliance Access when the available space on the disk of the source tree
Release Dir is less than this value (in Kbytes). Default value: 20000.
Changes to this parameter take effect at the next disk-space check.

27 March 2015 45
Alliance Access 7.1 on Alliance Web Platform

Parameter Description

Warning - MB Alliance Access issues a warning when the free space of one of the monitored file
systems hosting the database becomes less than this number of megabytes. The
file system is set in an exception state in the resources monitoring.
Default value: 5000. Minimum: 0. Maximum: 4190000.
If the value is 0, then no action is taken.
Changes to this parameter take effect at the next disk-space check.

Warning - Alliance Access issues a warning when available space on the disk of the Release
Release Dir Directory is less than this value.
Default value: 50000 (Kbytes).
Changes to this parameter take effect at the next disk-space check.

UNIX or Linux Alliance Access issues a warning when available space on the /tmp disk is less
only: than this value (in Kbytes).
Warning - Printer Default value: 10000. Minimum: 1024. Maximum: 200000.
Spool Changes to this parameter take effect at the next disk-space check.

5.1.10 Display Format


List of display format parameters

Parameter Description

Amount Specifies the convention used to separate decimals and units of a thousand:

Decimal-Comma/Thousand-Nothing, which corresponds to the ISO format. This is


the default value.

Decimal-Point/Thousand-comma, which corresponds to the American format.

Decimal-Comma/Thousand-Point, which corresponds to the European format.

Date The display format of the date: American date format is MM/DD/YY, European date
format is DD/MM/YY, ISO date format is YY/MM/DD. Default: European.
You must restart Alliance Workstation, to apply the changes to this parameter.

Time Specifies the time format:

Day of 24 Hours, which uses 24-hour clock notation, for example, 13:15:00. This is
the default option.

Day of 12 Hours, which uses 12-hour clock notation, for example, 01:15:00 p.m.

See also "Display/Print" on page 47.

46 Security Guide
Configuration and Security Parameters

5.1.11 Display/Print
Display/Print parameter

Parameter Description

FIN User Specifies whether to display or print the FIN User Header (block 3) of MT messages.
Header
The allowed values are:

Yes - display block 3 in the message details in the Text tab of the Message Details
area, and in the results of a message search. In addition, print block 3 in the printed
reports of message details, both from the GUI and from a Print message partner.

No - do not display block 3 in the message details, and do not print it in reports that
provide message details.
The default value is No.

5.1.12 Emission
List of emission parameters

Parameter Description

Corr. on Indicates the period of time (in minutes) after which a correspondent is put on hold for a
hold criteria real-time service if all emission attempts for that correspondent/real-time service have
failed during that period.
If set to 0, correspondents are never put on hold for a real-time service.
The possible values are numbers from 0 to 999. The default value is 10.
Any changes to this parameter take effect immediately.

EP Polling Indicates the period (in seconds) according to which the Alliance Access polls the
Timer database for the next message to send:

Maximum value: 300

Minimum value: 1

Default value: 30
You must restart the SWIFTNet Interface Services (SNIS) component, to apply the
changes to this parameter.

Retry Timer Indicates the timeout period (in seconds) between two attempts to emit a message:

Maximum value: 120

Minimum value: 0

Default value: 60
You must restart the SWIFTNet Interface component, to apply the changes to this
parameter.

27 March 2015 47
Alliance Access 7.1 on Alliance Web Platform

5.1.13 Event
Event parameter

Parameter Description

SNMP Max Indicates the maximum size of the event text distributed to SNMP managers. 0 means
Event Size that there is no maximum size. Default value: 2000.

5.1.14 File
File parameter

Parameter Description

File Digest Indicates the default file digest algorithm that Alliance Access uses to compute the
Algorithm digest on the payload file of the FileAct message if no file digest algorithm is provided by
the back-office application. The following values exist: SHA-1 and SHA-256. Default
value: SHA-256.
Changes to this parameter take effect immediately.

5.1.15 Message
List of message parameters

Parameter Description

Check EP/LT Activates the rejection of MT messages submitted with LTX when there is no LT
existence defined for the LTX BIC8 and the rejection of IA/FA messages when there is no
Emission Profile for the message Requestor DN/Service.
Possible values are On (activates the check) or Off (no check). The default value is
Off.
Changes to this parameter take effect immediately.

Default Indicates the default time (in minutes) to be added to the message creation date and
emission expiry time to calculate its emission expiry date and time.
This parameter applies only to messages submitted without an emission expiry date
and time.
Possible values are integers from 1 to 43200. The default value is 28800.
Changes to this parameter take effect immediately.
This parameter impacts InterAct and FileAct messages (RT or SnF). If a message
fails transmission, it is retried until the message expires (that is, until it reaches the
expiration date and time) or until the emission is manually cancelled.

Expansion Specifies the language that message expansion fields are displayed in. Default value:
Language English.
Changes to this parameter take effect when an application is restarted.

48 Security Guide
Configuration and Security Parameters

Parameter Description

LT load Starts the automatic allocation of logical terminal allocation.


balancing
Possible values are:

On - the messages originated by a destination can be transmitted by any logical


terminal which is logged in and assigned to that destination.

Off - the logical terminal specified in the message transmits the message.
Default value: Off.
You must restart the SWIFT Interfaces Services (SIS) component, to apply the
changes to this parameter.

Maximum File Indicates the maximum size of a file in Mbytes (Mb) that a back-office application can
Size send to Alliance Access.

Maximum value: 2048

Minimum value: 1

Default value: 250


You must restart the Application Interface Services (MXS) component, to apply the
changes to this parameter.

RMA Specifies whether RMA Authorisation is required for FIN Test and Training
authorisation messages. Possible values are:
for T&T
Not required

Required
Default value: Not required.
You must restart the SWIFT Interfaces Services (SIS) component, to apply the
changes to this parameter.

RTV Routing Controls the RTV routing information in a retrieved message. When this parameter is
set to:

Off - the routing_code field for a retrieved message is set to RTV

On - the disposition_address_code field for a retrieved message is set to RTV.


You must restart the SWIFT Interfaces Services (SIS) component, to apply the
changes to this parameter.
Default value: Off.

Common Ref Controls the calculation of the Common Reference, which is part of field 22 of Block
Calculation 4, in FIN messages that are input through message partners and that have the data
format CAS, RJE, DOS-PCC, or XML version 2. Alliance Access always calculates
the Common Reference in messages that a user enters manually.
The values are:

Yes - Alliance Access calculates the Common Reference, even it exists in field 22.

No - does not calculate the Common Reference in field 22. In this case, the values
of Validation level and Message Modification allowed are ignored, and a NAK
may be received if field 22 of the message contains incorrect information.
Default value: Yes.
You must restart the Application Interface Services (MXS) component to apply the
changes to this parameter.

27 March 2015 49
Alliance Access 7.1 on Alliance Web Platform

Parameter Description

FT Monitoring The number of days during which a file transfer with the status Completed or Aborted
Retention remains visible in the list of File Transfers in the Monitoring package.
The list can contain a maximum of 1000 completed or aborted file transfers. This limit
ensures that the performance of Alliance Access remains optimal. Therefore, if the
list contains 1000 completed or aborted file transfers, then Alliance Access removes
the oldest of those file transfers.
You must restart the SWIFTNet Interface component to apply the changes to this
parameter.
Maximum value: 30
Default value: 0
Regardless of the value set for this parameter, a restart of the servers will clear file
transfer records from Message Management > File Transfer Monitoring or
Monitoring > File Transfers.

Activate cold Determines if cold start processing should be automatically started upon receipt of an
start MT 082 report (with cold start indication) for FIN, or an xsys.005.002 report for
InterAct and FileAct.
Possible values are Activate and Deactivate The default value is Activate.
Changes to this parameter take effect immediately.

FIN CS Time Time margin (in minutes) applied by Alliance Access when performing cold start
Margin MT082 post-processing.
The minimum value is 0 and the maximum value is 780. The default value is 15.
Changes to this parameter take effect immediately.

W3C - Primary List of primary SWIFTNet connections to be used for handling W3C signature
SAG list computation and verification requests submitted with no SWIFTNet connections.
This is a comma-separated list of SWIFTNet connections, which is by default empty.
This parameter is applicable in the context of W3C signature Web services, either
exposed by means of a Web service or the Connector for T2S. For more information,
see the Alliance Access T2S Web Services Developer Guide or the Connector for
T2S Release Letter.

W3C - List of secondary SWIFTNet connections to be used to handle W3C signature


Secondary SAG computation and verification requests submitted with no SWIFTNet connections,
list when none of the SWIFTNet connections in the W3C - Primary SAG list is available.
This is a comma-separated list of SWIFTNet connections, which is by default empty.
This parameter is applicable in the context of W3C signature Web services, either
exposed by means of a Web service or the Connector for T2S. For more information,
see the Alliance Access T2S Web Services Developer Guide or the Connector for
T2S Release Letter.

5.1.16 Network
List of network parameters

Parameter Description

SWIFTNet Maximum delay (in seconds) that Alliance buffers an input message before it is
Batching Timeout sent. SWIFT determines the final value used. Default value: 2.
You must restart the SWIFT Interfaces Services (SIS) component, to apply the
changes to this parameter.

SWIFTNet Max Maximum number of FIN APDUs that can be sent in a single DATA PDU. SWIFT
batch count determines the final value used. Default value: 30.
You must restart the SWIFT Interfaces Services (SIS) component, to apply the
changes to this parameter.

50 Security Guide
Configuration and Security Parameters

Parameter Description

Reconnect Timer Indicates the time (in minutes) after which the SWIFTNet Interface component
(SNIS) attempts to reconnect an interrupted profile. Default value: 20. Minimum: 1.
Maximum: 300.
You must restart the SWIFTNet Interfaces Services (SNIS) component, to apply
the changes to this parameter.

Preferred Order Used by the Message Preparation application to propose a default value for the
preferred network when the receiver is a wild address, that is, the network address
is not in the correspondent file. The default display order is SWIFT, APPLI,
OTHER, IPLA.
Changes to this parameter take effect when the application is restarted.

Usersync - Max Specifies the number of attempts that are allowed to reconnect a failed
Retries communication session with the SWIFT network. Default value: 20.
You must restart the SWIFT Interfaces Services (SIS) component, to apply the
changes to this parameter.

Usersync - Max Specifies the duration (in minutes) for which attempts to reconnect a failed
Time communication session with the SWIFT network are made. Default value: 30.
You must restart the SWIFT Interfaces Services (SIS) component, to apply the
changes to this parameter.

Usersync - Retry Specifies the time-out period (in seconds) between reconnect retries. Default value:
Timer 120.
You must restart the SWIFT Interfaces Services (SIS) component, to apply the
changes to this parameter.

5.1.17 Performance
List of performance parameters

Parameter Description

Active Controls whether correspondents are checked to see whether they have an active
Correspondent status, before sending a message. The possible values are "On" or "Off". Default
value: On.
You must restart the SWIFTNet Interfaces Services (SNIS) component, to apply
the changes to this parameter.

FIN Keyword Controls whether keywords are extracted from incoming (output) MT messages.
Extraction The possible values are "On" or "Off". Default value: On.
You must restart the SWIFTNet Interfaces Services (SNIS) component, to apply
the changes to this parameter.

Maximum Read Disk I/O in MB/sec used to read from the database disks when a Recovery Backup
Rate is created. Minimum: 0. Maximum: 1024. Default value: 0. If the value is 0, then
maximum disk I/O is used.
Change to this parameter take effect at the next recovery backup creation.
This parameter is ignored unless the Alliance servers are running and option
14:DATABASE RECOVERY is licensed.

MQSA Controls whether the writing of some interventions is suppressed. The possible
Interventions values are "None", "All", or "System". Default value: None.
You must restart the SMQS component, to apply changes to this parameter.
This parameter applies to the WebSphere MQ Interface for Alliance Access
(MQSA). It does not apply to the WebSphere MQ Host Adapter.

27 March 2015 51
Alliance Access 7.1 on Alliance Web Platform

Parameter Description

MX Keyword Controls whether keywords are extracted from incoming (output) MX messages.
Extraction The possible values are "On" or "Off". Default value: On.
You must restart the SWIFTNet Interfaces Services (SNIS) component, to apply
the changes to this parameter.

Routing Controls what types of interventions are suppressed. The possible values "All",
Intervention "System generated only", or "None". Default value: None.

5.1.18 Print
List of print parameters

Parameter Description

Message Search Specifies the maximum number of items that can be printed in a Message Search
Results Report. Default value: 1024. The value "0" means that no limit is set.

Skip Specifies whether Printer message partners print notifications without system or
Interventions user interventions. This does not apply to transmission notifications. The default
value is No, with notifications being printed with system or user interventions.
Setting this parameter to Yes saves paper when notifications are printed.

ST200-like Specifies whether Printer message partners print messages in an ST200-like


Format format, with an eye-catcher and warning banner. This parameter has no effect
when messages are printed to a file. Default value: No.

See also "Display/Print" on page 47.

5.1.19 Queue
Queue parameter

Parameter Description

Threshold Frequency of alarm generation - the number of messages that can be added above
a queue threshold or the number of overdue message instances before a new
alarm will be generated. Minimum: 20. Maximum: 100. Default value: 20.
Changes to this parameter take effect at the next alarm.

5.1.20 Receiver
List of receiver parameters

Parameter Description

Default HQ for Specifies the receiver for system messages 074. Default value: SWHQBEBBBCT.
MT074

Default HQ for Specifies the receiver for system messages 090. Default value: SWHQNLNLXXX.
MT090

5.1.21 Reception
Reception parameter replaced by GUI option
As of Alliance Access 7.0.75, the SnF RProf Resequencing global system configuration
parameter has been discontinued. It is replaced by an OSN Resequencing GUI option at the

52 Security Guide
Configuration and Security Parameters

individual Store-and-Forward reception profile level. As a result, Alliance Access applies OSN
resequencing to a Store-and-Forward reception profile if its OSN Resequencing option is
selected or if its SAA_DO_RESEQ_<RPName> environment variable is set to On. Alliance Access
does not apply OSN resequencing to a Store-and-Forward reception profile only when both
indicators are off.
For more information on the OSN Resequencing GUI option, see the section on the
Configuration tab of the Reception Profile Details window in the Configuration Guide.

5.1.22 Reporting
Reporting parameters

Parameter Description

Mail server address Defines the HOST:PORT that will be used by the
Operational Reporting mail server. HOST can be
either an IP address or a hostname.
Changes to this parameter take effect immediately.

Activate Reporting If set to Activate, Operational Reporting is


activated. This will copy all messages to the
reporting data store, which may take some time,
depending on the number of messages. Set this
parameter to Deactivate to deactivate Operational
Reporting, which will remove all message data
from the reporting data store.

5.1.23 RMA
RMA parameter

Parameter Description

Auto Refresh If this parameter is set to No, then the automatic refresh of the view lists is disabled
in the Relationship Management application. Default value: Yes.
You must restart the Relationship Management Application (RMA) component, to
apply the changes to this parameter.

5.1.24 Shutdown
List of shutdown parameters

Parameter Description

Delayed After a request to stop the servers, this is the number of seconds delay before the
GUI applications are terminated. Default value: 120.

Forced After a request to stop the servers, this is the number of seconds delay before the
server processes are terminated. Normally the server processes stop before this
time has elapsed. Default value: 240.

27 March 2015 53
Alliance Access 7.1 on Alliance Web Platform

5.1.25 System
System parameter

Parameter Description

Startup Mode This parameter enables Alliance Access to start automatically after the machine
where the Alliance Access instance is installed is rebooted.
On UNIX or Linux, this parameter can have the following values:

Automatic - Alliance Access starts as a result of starting the Alliance Access


bootstrap

Manual - An operator must explicitly start Alliance Access.


Default value: Manual.

On Windows, this parameter can have the following values:

Service - Alliance Access runs as a Windows service under control of the


Alliance Access Bootstrap service.

In Service mode, mapped network drives cannot be used.

Tip To start Alliance Access automatically after a reboot, select


Service and use the Windows Service Management interface to
configure the Alliance Access Bootstrap service to start
automatically

Normal - Alliance Access does not run as a Windows service.


Default value: Normal.

SNMP Heartbeat This parameter enables you to activate/deactivate the SNMP heartbeat
Interval functionality and, if activated, to define the number of seconds between two
SNMP heartbeats.
Possible values are 0 and 120-900 (the number of seconds between two SNMP
heartbeats). 0 means that the heartbeat functionality must not be activated.
All values less than 120 mean the heartbeat is not active.
Changes to this parameter will take effect at the next heartbeat or at most 900
seconds later if the heartbeat is not active.

SNMP Heartbeat This parameter enables you to provide the name of the distribution list to be used
Dist. List for sending SNMP heartbeat trap to SNMP servers.
Create this distribution list and populate it with the SNMP server(s) to which the
SNMP heartbeat must be sent.
The list name can be up to 15 characters long.
Changes to this parameter will take effect at the next heartbeat.

5.1.26 Traffic Recon


Traffic Recon parameter

Parameter Description

Delivery Notif If set to Yes, then Traffic Reconciliation generates notifications for each matched
message instance. Default value: Yes.

54 Security Guide
Configuration and Security Parameters

Parameter Description

FIN Mult. If set to yes, FIN messages can be reconciled multiple times.
reconciliation Default value: No.

Msg Interval (in seconds) at which Alliance Access reconciles messages.


reconciliation Possible values 60-600. Default value: 300.
cycle
Changes to this parameter take effect at the next reconciliation poll.

5.1.27 WebSphere MQ
List of WebSphere MQ parameters
If the licence package 13:MQ HOST ADAPTER is installed, then the following parameters are
available:

Parameter Description

Connection Mode Specifies the mode that the Web Sphere MQ interface of Alliance Access uses to
connect to a Queue Manager. The options are:

Client - The WebSphere MQ interface can connect at the same time to multiple
Queue Managers which are located on the same host or on a different host as
the MQ Adapter.

Note See the WebSphere MQ client and WebSphere MQ server


components in the WebSphere MQ Interface User Guide for
information about setting the environment variables for
"MQSERVER" and "MQ channel table".

Server - The WebSphere MQ interface can connect to one Queue Manager


located on the same host as Alliance Access.
Default value: Server.
You must restart the Application Interface Services (MXS) component, to apply the
changes to this parameter.

Input Message Limits the number of messages that Alliance Access reads per second from all the
Rate Limit WebSphere MQ queues that are configured in Alliance Access.
The default value is 0, which means that the incoming WebSphere MQ traffic is not
limited. Mininum: 0. Maximum: 999.
Before you change this parameter, you must disable all the Websphere MQ
message partners.

Recovery Time - The time interval, in seconds, after which the first attempt to reopen the
Initial communication session with WebSphere MQ is made in case of a broken
connection. Default value: 60.

Recovery Time - The increase of the time interval, in seconds, between consecutive attempts to
Increment reopen a WebSphere MQ session. Default value: 30.

Recovery Time - The maximum time interval, in seconds, between consecutive attempts to reopen a
Max WebSphere MQ session. Default value: 600.

5.2 Security Parameters


Description
A number of security parameters exist in Alliance Access which apply globally to all operators.

27 March 2015 55
Alliance Access 7.1 on Alliance Web Platform

The security parameters have default values, as outlined in "Classes of Security Parameters" on
page 56. After Alliance Access is installed, the Security Officers can change the values of the
parameters by means of the Alliance Access Configuration. Only a Security Officer (left security
officer or right security officer) can make changes to the values of any of the security
parameters, and the changes must be approved by both the left security officer and right
security officer.
For more information on changing parameters, see the section on security parameters in the
Configuration Guide.

5.2.1 Classes of Security Parameters


5.2.1.1 Alarm

List of Alarm parameters

Component Parameter Description

BSS Path of Script Full pathname of the user-defined script that Alliance Access runs
File when an Alarm Event occurs.
It must be:

owned by the Alliance Administrator

located in a directory accessible by this user

UNIX or Linux: it must be compliant with the requirements of the


UNIX or Linux exec system call, regarding the execution of an
interpreter file.
Maximum length: 255
Default value: none

5.2.1.2 Backup integrity

List of Backup integrity parameters

Component Parameter Description

BSS Backup Specifies the type of digest that is calculated to ensure the integrity of
integrity archive backups.
Possible values are:

Fast - integrity of the backup is based on a digest covering the


metadata.

Full - a second digest is added, covering the data in the backup.


Default value: Full

56 Security Guide
Configuration and Security Parameters

5.2.1.3 Mesg Archive

List of Mesg Archive parameters

Component Parameter Description

BSS Archive Method Possible values are:

Normal - create the archive (all messages must be completed).

Destructive - do not create archive, all messages must be


completed, and are deleted from the database.
Default value: Normal.

5.2.1.4 Message

List of Message parameters

Component Parameter Description

BSS Check Indicates whether the existence of an RMA authorisation is checked


authorisation during message entry or message modification.
exist Note: If you have the licence option 07:STANDALONE REC, then
this parameter indicates whether an RMA check is performed
whatever the network is (OTHER included).
Default: Yes.

MXS Continue on This parameter is only applicable for message partners configured
LAU failure with the WebSphere MQ connection method.
This parameter is only applicable for message partners configured
with the WebSphere MQ connection method.
When this parameter is set to Off, Alliance Access will reject a
message that arrives on an input message partner if the LAU check
fails. At the same moment, the message partner sessions will be
stopped.
When the parameter is set to On, messages arriving from an input
message partner that fail the Local Authentication check will still be
accepted by Alliance Access, and the message partner will continue
to process messages, while a specific event is generated. In such a
situation, you should check the routing rules of all message partners
ensure that the appropriate behaviour is achieved (for example, to
move the messages to the _MP_emi_sec queue and force them to
pass through authorisation). Assigning the messages to a specific
UNIT can help you to control who can handle these exceptions, as
well as locating them back in the message database.
To change the default behaviour, the routing rule(s) handling the LAU
failure using the new LAU_RESULT_FAILURE routing keyword
should be set as first routing rule(s) of _AI_from_APPLI.
For changes to this parameter to take effect, the Application Interface
component must be restarted.

BSS FIN CS time Time margin (in minutes) applied by Alliance Access when
margin performing cold start MT082 post-processing.
The minimum value is 0 and the maximum value is 780. The default
value is 15. Changes to this parameter take effect immediately.

27 March 2015 57
Alliance Access 7.1 on Alliance Web Platform

Component Parameter Description

BSS Journalise Msg If this parameter is set, then the text block from the message is
Text included in the message event description. A change to this
parameter takes effect after the SWIFT Interface component is
restarted.
Possible values are:

Message Text Journalised

Message Text Not Journalised


Default value: Message Text Journalised

BSS Message Indicates the type of action that is performed by default on the
Repair Action outstanding live messages, which are flagged with possible duplicate
emission (PDE), if the database is partially recovered.
Possible values are:

Prompted: the user can select an option when the tool is


launched.

None: the messages are routed as defined

Complete: the messages are completed

Investigate: the messages are routed to the _MP_recovery


queue for investigation.
Default value: Prompted
This parameter appears when either 14:DATABASE RECOVERY or
13:HOSTED DATABASE are licensed.

SIS MT398 Specifies whether the SWIFT Interface component performs a


message proprietary authentication code (PAC) verification on messages
extraction embedded in the MT 398. A change to this parameter takes effect
after the SWIFT Interface component is restarted.
Possible values are:

Off

On
Default value: Off.

BSS Re-activation Determines whether completed messages are re-activated at a


Scope routing point.
Possible values are:

Full: all the allowed routing and exit points appear.

Partial: only exit points appear.

Restricted: The target re-activation queue is selected


automatically, as follows:

input messages: Text Modification queue

output messages: Modification After Reception queue


Default value: Full.

58 Security Guide
Configuration and Security Parameters

Component Parameter Description

SIS Retrieved Indicates whether the SWIFT Interface component extracts the
message contents of MT 021 of output messages into separate messages. A
extract change to this parameter takes effect after the SWIFT Interface
component is restarted.
Possible values are:

On

Off
Default value: Off.

5.2.1.5 Operator

List of Operator parameters

Component Parameter Description

BSS Prefix Operator If this parameter is activated, then Alliance Access validates the BIC8
Name prefix of an operator name when the operator is created. If an
operator name is modified, then the name is validated only if the
operator name already has a BIC8 prefix.
The prefix must meet the following conditions to be valid:

The prefix must be a BIC8 (upper case) followed by an


underscore (_) character.

The BIC8 must be one of the licensed destinations of the Alliance


Access instance (either production, or Test and Training).

If the creating operator has one or more restricted BIC


delegations, then the prefix must be a BIC that is delegated to the
creating operator.

If the created operator has one or more restricted BIC delegations,


then the prefix must be a BIC that is delegated to the created
operator.

If the created operator has one or more restricted profile


delegations, then the names of the selected profiles must start
with a BIC8 that is delegated to the creating operator.
This parameter is useful for institutions that use or manage multiple
BICs.
Possible values are:

Yes: Validate the prefix of an operator name

No: Deactivate the validation of the prefix


Default value is No.

27 March 2015 59
Alliance Access 7.1 on Alliance Web Platform

Component Parameter Description

BSS Restrict The left security officer and right security officer of a service bureau
Delegation use this feature when creating local security officers. Indicates
whether restrictions are applied for operator profiles, units, and
destinations.
This parameter does not affect the left security officer and right
security officer because they always have unrestricted access to
operator functions.
Possible values are:

Yes: An operator who is adding a new operator can only select


operator profiles, units, and licensed destinations from a restricted
list.

If set to Yes, then this parameter overrides the Restrict


Functions parameter.

No: Delegation is not possible.

Default value: No.

BSS Restrict Specifies whether the operator-related functions (open, print, add,
Functions modify, approve, or remove) are restricted.
Possible values are:

Yes:
An operator with the appropriate entitlements can only perform
these functions on the operators that belong to a subset of the
same units as the operator performing out the action.

For more information, see "Definition of Units and Restrict


Functions" on page 80.

No: these functions are not restricted, and an operator with the
appropriate entitlements can search for, open, print, add, modify,
approve, or remove operators belonging to any unit.
Default value: No.
This parameter does not affect the left security officer and right
security officer because they always have unrestricted access to
operator functions.

BSS Software Specifies the operator profile that is assigned as the owner of the
Owner Profile software. An operator with that profile can perform specific actions on
Alliance Access, such as exporting configuration data or querying the
database for messages or events.
If this parameter is empty or invalid, then the software owner operator
is disabled.
The servers must be restarted for changes to this parameter to take
effect.

60 Security Guide
Configuration and Security Parameters

5.2.1.6 Password

List of Password parameters

Component Parameter Description

BSS Illegal Patterns Specifies the patterns of characters that are not allowed in
passwords. An error message appears if any operator tries to create
a password which contains one of the defined characters or
character strings.
Both security officers must approve any changes to this parameter.
Type a string consisting of patterns separated by |. Changes to this
parameter take effect the next time an operator changes a password.
Maximum length: 255
For example, @|$|Bob prohibits the use of the following characters in
passwords:
@, $, or Bob

BSS Master Period Specifies the number of days after which the security officers have to
change the Master Passwords.
The possible values are 0 through 365.
Default value: 100.
A value of 0 means that the security officers are never forced to
change their passwords.

BSS Max Bad Pwd Specifies the maximum number of times that a user can enter
incorrect passwords before the sign-on action is refused. Both
security officers must approve any changes to this parameter.
Alliance Access monitors invalid password entries. A parameter can
be used to disable an operator who has not entered a valid password
within a defined number of attempts. When disabled, an operator
cannot sign on to Alliance Access (even with the correct password)
until a security officer or an operator with the correct permissions re-
enables it.
If a security officer exceeds the specified number of attempts (when
signing on or when changing their password) , they are disabled for a
period of 10 minutes.
Possible values are 0 through 100
Default value: 5.
If the value is set to 0, then an unlimited number of password entry
attempts is allowed (this is not recommended for security reasons).

BSS Min Pwd Specified the minimum length of the user password.
Length Possible values are 4 through 20.
Default value: 6.

BSS Nbr Retained Specifies the number of user passwords that Alliance Access keeps
Pwd track of.
Whenever a user password is successfully updated, the old user
password is written to that user's password history file. Alliance
Access can check a user's password history file and prevent the user
from changing the password to one that has been used before.
Both security officers must approve any changes to this parameter.
Possible values are 0 through 20.
Default value: 10.

27 March 2015 61
Alliance Access 7.1 on Alliance Web Platform

Component Parameter Description

BSS Reset Peer Specifies whether the left security officer can reset the right security
Officer Passwo officer's password to the Master Password which was valid at the
time of installation, and vice versa. This is useful if a security officer
forgets a password. An event is written to the Event Log each time
that a password is reset.
Possible values are:

Yes

No: the security officers cannot reset each other's password.


Default value: No.

BSS Sec Officer One Activates the use of one-time passwords for the security officers. The
Time Pwd value of this parameter applies to both security officers.
Both security officers must approve a change to this parameter
before it takes effect. Until both security officers have not approved
the change, the security officers must log on using their user-defined
password.
Possible values are:

Yes: If the Sec Officer OTP Srv Group parameter is correctly set
and approved, then the left security officer and right security
officer can use one-time passwords.

No: the master passwords have to be used at the next sign-on of


the left security officer and the right security officer, and their
password must be changed as if it was the first logon.
Default value: No.

BSS Strong Specifies whether passwords are validated as being strong from a
Validation security perspective. Changes to this parameter become effective
when an operator changes the password. If the new password fails
the strong validation test, then an appropriate error appears to the
operator indicating that the password is not compliant with the strong
validation rules.
Both security officers must approve any changes to this parameter.
Possible values are:

Yes: validates that the user password contains a combination of


alphabetic and numeric characters, with at least 1 numeric
character.

No
Even if the value is set to No, all the other validation rules (such as
illegal pattern verification and minimal number of characters)
remain applicable.
Default value: No.

BSS User Period Specifies the number of days that a user can use a password before
the password must be changed. Both security officers must approve
any changes to this parameter.
Possible values are 0 through 120.
If the value is set to 0, then passwords are valid indefinitely (this is
not recommended for security reasons).
Default value: 30.

62 Security Guide
Configuration and Security Parameters

Component Parameter Description

BSS Sec Officer Specifies the authentication (OTP) server group that is assigned to a
OTP Srv Group security officer if both security officers are configured to use
authentication by means of the Sec Officer One Time Pwd
parameter.
This is a textual parameter. By default, this value is empty.

5.2.1.7 Reports

List of Reports parameters

Component Parameter Description

BSS Root Path for The path name which is the top level of the directory tree where
Report File report files are stored.
Maximum length: 64
The default location is:

UNIX or Linux: $ALLIANCE/usrdata/report

Windows: C:\Alliance\Access\usrdata\report

5.2.1.8 RMA

List of RMA parameters

Component Parameter Description

RMS Auto Accept Indicates whether Alliance Access automatically applies the updates
Updates that it receives for an Enabled authorisations-to-send.
A change to this parameter is immediately taken into account.
Default value: No

RMS Clean up Stale Specifies the minimum number of days that an authorisation or a
Auth. query must be kept before it can be removed.
A change to this parameter becomes effective immediately.
Possible values are 1 through 365.
Default value: 180

RMS Needs Status Indicates whether an operator must confirm the revocation or
Confirmation rejection of an authorisation.
A change to this parameter becomes effective immediately.
Default value: Yes

27 March 2015 63
Alliance Access 7.1 on Alliance Web Platform

5.2.1.9 Signoff

List of Signoff parameters

Component Parameter Description

BSA Timeout Specifies the number of seconds after a Signon Timeout occurs that
an operator can be inactive on Alliance Workstation before the
operator is logged off automatically from Alliance Workstation.
Possible values are 0 through 3600.
Default value: 1800
If the value is set to 0, then the Alliance Workstation is not signed off
automatically.

BSS WS Session The number of seconds that a web-service operator session can
Timeout remain inactive before the session is stopped and removed.
The possible values are 1800 through 5400. Default value: 2700.

5.2.1.10 Signon

List of Signon parameters

Component Parameter Description

BSS Multiple Specifies the numbers of concurrent sign-ons to Alliance Access that
the same operator is permitted to perform.
Possible values are 1 through 10.
Default value: 1
For example, if the value is set to 2, then the operator can sign on to
the same instance of Alliance Access from two different Alliance
Workstations. However, an attempt to log on from a third Workstation
will be rejected.
If a login attempt fails because the maximum number of sessions for
the operator has been exceeded and the operator attempts to log in
again, a prompt is displayed that asks if Alliance Access can
terminate the session that has been idle for the longest time. If the
operator accepts, the login proceeds. Otherwise, the login is rejected.

BSA Timeout Specifies the number of seconds that an operator can be inactive,
before the operator has to re-enter the password. For more
information, see "Use of timeout parameters".
Possible values are 60 through 28800.
Default value: 600

Use of timeout parameters


Following a successful sign-on to Alliance Access, an inactivity timer is started, which is reset
each time an operator performs some activity within Alliance Access. When the inactivity timer
expires, all windows on the screen are frozen. The same operator must re-enter a password
before being allowed to continue. Having re-entered the correct password, all windows are
reinstated and the operator can continue work.
This feature helps to prevent unauthorised users from using Alliance Access, if an operator is
called away. It is not intended to replace the normal practice of signing off from Alliance Access,
for example, when an operator leaves to take a break.

64 Security Guide
Configuration and Security Parameters

Alliance Access uses a total of four session timeout parameters related to operator sign-on,
three of which are global security configuration parameters:

Signon Timeout

Signoff Timeout

WS Session Timeout
In addition, the operator profile definition contains the following parameter: Access Control >
Signon > WS Session Timeout.
Alliance Web Platform contains the Session Expiry Timeout parameter, which is found in the
configuration of the Alliance Web Platform 7.0 package.
On Alliance Web Platform, when the value of the Session Expiry Timeout parameter is smaller
than the value of the WS Session Timeout parameter, and when an operator is inactive for a
time period equal to the parameter Session Expiry Timeout, Alliance Web Platform ends the
session. The message "You have been logged out because the user session expired" is
displayed and you must re-enter the operator name and password. This is the recommended
set-up and behaviour.
On Alliance Web Platform, when the value of the WS Session Timeout parameter is smaller
than the value of the Session Expiry Timeout parameter, and when an operator is inactive for
a time period equal to the value of the WS Session Timeout parameter, Alliance Access ends
the session. The operator does not see this until he tries to perform an action, when a message
pop-up is displayed, as follows:

For the RMA or Configuration GUI package, the following message is displayed: "Your
Alliance Access/Entry session is no longer valid. Please logout and login again."

For the Message Management GUI package, the following message is displayed: "Failed to
communicate with Alliance Access/Entry. The connection to Alliance Access/Entry has
dropped." In this case, it is also necessary to log out and log in again.

For the Monitoring GUI package, there is a built-in mechanism to keep the session alive,
therefore the sessions never expire.

Note If the value of the WS Session Timeout parameter in the operator profile is set to
0, then the value of the global WS Session Timeout parameter is taken into
account. If the value of the WS Session Timeout parameter in the operator profile
is other than 0, then this value is used by the application.

On Alliance Workstation, when an operator is inactive for a time period equal to the value of the
Signon Timeout parameter, a pop-up is displayed that prompts the operator to re-enter his
password. If the operator does not provide his password, then the pop-up disappears after a
period of time equal to the value of the Signoff Timeout parameter.

27 March 2015 65
Alliance Access 7.1 on Alliance Web Platform

5.2.1.11 System

List of System parameters

Component Parameter Description

IPLA Allow Starting Indicates if the Integration Platform (IPLA) component can be started.
IPLA Possible values are Yes and No.
Default value: No
Changing the value from Yes to No is considered the next time that
there is an attempt to start IPLA, either manually or when Alliance
Access starts. Changing the value from No to Yes allows starting the
IPLA component manually.
If the IPLA component has been stopped, it must be started manually
even if the value is set to Yes. Afterwards, the IPLA component will
start automatically.
The security mechanisms of Alliance Access (such as the calculation
of a database signature per data record) protect the messages and
files processed by IPLA.

SSS Authenticate Indicates whether MT971 must be authenticated. A change to the


MT971 parameter will be taken into account immediately.
Default value: Yes

BSS Disable Period The number of calendar days during which an enabled operator must
sign on to Alliance Access. Otherwise, the status is changed to
disabled.
Possible values are 0 through 999.
Default value: 0
If this parameter is set to 0, then operators are not disabled
automatically, if they do not sign on.
A value of 0 cancels automatic disable. Changes to this parameter
will take effect at midnight or at the next restart of the Alliance
servers.

66 Security Guide
Configuration and Security Parameters

Component Parameter Description

BSS RPC Communication with Alliance Web Platform is always started with
Authentication SSL enabled, and server authentication is required. Therefore,
changes to this parameter do not affect the communication with
Alliance Web Platform.
For Alliance Workstation, this parameter specifies whether the
communication between Alliance Access and Alliance Workstation is
encrypted. Only when the parameter is set to "Data Integrity" or
"Data Confidentiality" can the Alliance Access servers initialise the
communication process with SSL enabled. If SSL is enabled, then
Alliance Workstation can also use Server Authentication. For more
information, see the System Management Guide.
This parameter provides additional security checks on client
processes that make Remote Procedure Calls (RPC) to server
processes.
Possible values are:

Off - processes making RPCs are not checked to ensure that they
are authenticated.

Process Authentication - processes making RPCs are checked


to ensure that they are authenticated.

Data Integrity - in addition to Process Authentication, Alliance


calculates a check value based on the character field data in the
RPC call. The check value and the RPC call are passed to the
server. The server recalculates the check value from the RPC
data, and compares it to the check value that it received. This
ensures the integrity of the RPC data. If any changes have been
made to the data, then the check values will not match.

Data Confidentiality - in addition to Data Integrity, the


following RPC call data is encrypted to ensure confidentiality:

all fields that are currently encrypted in the database (such as


the operator password).

all message details that are derived from the message text.
Default value: Process Authentication.
Alliance Access must be restarted for changes to this parameter to
take effect.

BSS Software Check Indicates whether the system runs the Integrity Verification Tool to
at Startup check the integrity of the software when Alliance Access is started.
Default value: Yes

Data confidentiality
If a large number of message templates are assigned to a unit, then using the higher levels of
RPC authentication affects the performance of the Message Creation entity. When the Data
Confidentiality option is used, an operator who belongs to that unit will find that the Message
Creation entity opens very slowly. If more than 50 message templates are in use, then it is
recommended that you use the low speed mode setting, which allows fewer items to be
displayed more quickly. At this setting, only 50 records are retrieved each time that a list of
items appears.

27 March 2015 67
Alliance Access 7.1 on Alliance Web Platform

Warning The Data Confidentiality mode is CPU-intensive. When selected, it significantly


decreases the overall throughput of Alliance Access. Therefore, this mode is not
recommended for high-throughput configurations.

5.2.1.12 User Mode

List of User Mode parameters

Component Parameter Description

BSS Housekeeping In housekeeping mode either a single operator is allowed to sign on


User Mode or multiple operators are allowed to sign on.
Possible values are:

Single

Multiple
Default value: Single.
Alliance Access must be restarted for changes to this parameter to
take effect.

5.2.1.13 User Space

List of User Space parameters

Component Parameter Description

BSS Root Path for Location where the User Space directories are to be created. These
User Space directories are associated to operators using the Web Platform.
Maximum length: 64

Windows: C:\Alliance\Access\usrdata\userspace

UNIX or Linux: $ALLIANCE/usrdata/userspace

68 Security Guide
User Management

6 User Management

6.1 Management of User Accounts


Overview
Alliance Access uses various security techniques to control access to user accounts, as outlined
in the following sections.

6.1.1 LDAP User Authentication


Why use LDAP authentication
LDAP allows institutions to use any existing user directories to control access to a range of
Alliance products. LDAP directories can be used to authenticate (user name and password) the
users defined in those Alliance products. LDAP offers numerous additional security rules for
password validation, as well as several other features to meet the needs of the most demanding
password policies. LDAP allows the implementation of specific security rules in addition to those
offered by default in Alliance Access.

LDAP overview

Query
Query

Response
LDAP Alliance Access Logon:
directory server User Interface

D0540177
How LDAP authentication works
LDAP is used to authenticate the users only (username and password verification). The users
are created on the Alliance Access server, but can be mapped to an LDAP identifier used for
verification of the credentials. Profiles and units are assigned to users on the Alliance Access
server.
The following process occurs when LDAP authentication is used:

1. A user logs on to a user interface (Alliance Workstation, or Alliance Web Platform) with the
local operator name and the LDAP password.

2. The Alliance Access server receives the logon request and checks whether the operator is
authenticated locally, through One-Time Passwords or through LDAP. If the operator is
authenticated locally or through One-Time Passwords, then the behaviour is as described
in the previous sections.

3. If the operator is authenticated through LDAP, then the operator name is mapped to an
LDAP identifier, if present. Otherwise, the operator nickname is forwarded to the LDAP
server.

4. The password and the LDAP identifier or operator nickname are forwarded to the LDAP
server.

27 March 2015 69
Alliance Access 7.1 on Alliance Web Platform

5. The LDAP server authenticates the user.

6. If the user is authenticated successfully, then the user can log on using the permissions
assigned to him in Alliance Access.

What you must set up for LDAP authentication


Configuring Alliance Access for LDAP authentication includes the following:

Four-Eyes Approval mechanism requiring both security officers (left security officer and right
security officer), or users with left and right LDAP Approve permission.

At least one LDAP directory must be available. A primary LDAP server group must be
configured in Alliance Access Web Platform, from the Security Definition application. A
secondary LDAP server group may be configured. For more information, see LDAP server
groups in the Configuration Guide.

The host name and port number of the LDAP authentication server or servers must be known
to Alliance Access.

6.2 Alliance Password Modes


Overview
Alliance Access supports different password modes which dictate the type of operator password
that an operator must enter when signing on to Alliance Access, as shown in the following table.

Password Mode Description

User Password Mode In User Password Mode, operators must first sign
on using the four-character system-generated
password. Subsequently they can sign on with
passwords generated by the operators themselves.
Alliance Access provides strict controls over the
length and the nature of user-generated
passwords.
This mode allows operators to use passwords that
they can remember easily, while the Alliance
Access controls ensure that all user passwords
meet certain minimum requirements.

One-Time Password Mode One-time passwords are generated by a hardware


token and authenticated by an authentication
server. The usage of one-time passwords is set
per operator. It is activated when creating the
operator. For more information, see "Authentication
Server Groups and One-Time Passwords" on page
81, and "Operators" in the Configuration Guide.

LDAP Password Mode In LDAP Password Mode, the user name and
password are validated against an LDAP directory.
The usage of the LDAP Password Mode is set per
operator. It is activated when defining the operator.
For more information, see "LDAP User
Authentication" on page 69 and "Operators" in the
Configuration Guide.

70 Security Guide
User Management

6.3 Password Renewal


Overview
The regular renewal of passwords provides one of the best means by which passwords can
remain confidential to their owners. Providing that the passwords are not weak (see "Choice of
Passwords" on page 82), the simple practice of updating a password after a reasonable
period of use must be encouraged.
Alliance Access provides security officers with a means by which the number of days that a
password remains valid may be controlled. This period varies according to the type of
password. For more information, see "Password" on page 61.

6.4 Resetting User Passwords


Overview
If a user forgets a password, or if a security officer suspects that a particular operator's
password has been compromised, then a security officer (or an operator with the Approve
Operator entitlement) can use the Reset User Pwd command to reset the user password.
The password then becomes no longer valid for future sign-ons.
In User Password Mode, following such a reset, the operator must sign on to Alliance Access
using a system-generated password, at which point the operator is prompted to enter a new
user-generated password. The operator may not be able to sign on using the previous system-
generated password that was assigned to them because any changes that have since been
made to the operator's definition (for example, a change to the profile) or any updates to the
Master Password mean that the previous system-generated password is now no longer valid for
that operator. The security officers must therefore display both parts of the current system-
generated password for the operator, and pass each part, in turn, to the operator in question for
use in the next sign-on.
If the password mode is set to One-Time Password, then the Reset User Pwd command has
no effect.

6.5 Defining Alliance Access Operators


Purpose
The Security Officers must define all Alliance Access users. Any Alliance users (such as System
Administrator) must first be defined before they can sign on and access Alliance functions.

Delegation of operator definitions


Initially, only the left security officer and the right security officer can define new operators.
When the entitlement to create or modify operator definitions has been assigned to another user
(for example, to a System Administrator), then that user may also define new Alliance operators
(although such definitions must also be approved, as described further).

Operator definition
The creation, modification, and approval of operator definitions are performed with the Security
Definition entity. Each operator definition defines:

the full name of that operator

the operator nickname used by that operator when signing on to Alliance

27 March 2015 71
Alliance Access 7.1 on Alliance Web Platform

If you are implementing Alliance in a service bureau, then see also "Support for Service
Bureau" on page 72.

the current status of the operator (enabled or disabled, approved, or unapproved)

on AIX or Solaris only, whether terminal restriction applies to that operator and, if so, at which
terminals that operator is allowed to sign on

the units to which the operator belongs (not applicable for CRnet users)

the assigned operator profile(s)

the authoriser DN for FileAct

on AIX or Solaris only, the printers and terminals to which an operator has access. These can
be defined on the server (directly or through X-emulation) or by using an Alliance workstation.

Operator status
Following the initial definition of an operator, that operator first has the status disabled and is not
yet approved (see further). The current status of an operator shows whether that operator is:

enabled or disabled

unapproved

awaiting approval - by the left security officer or the right security officer

approved - by both the left security officer and the right security officer
Other security parameters, such as the minimum password length, are defined at a system level
and, therefore, apply to all operators.
New operators must be assigned an initial system-generated password by security officers (see
"Using Operator Profiles" on page 79).

6.6 Support for Service Bureau


Overview
With the correct security parameter set, the service bureau left security officer and right security
officer can create "local" security officers for each of the SWIFT user institutions operating
through the bureau.
The scope of Operator Profiles, Units, and Destinations that a local security officer can assign to
other operators, is limited to a subset defined by the left security officer and the right security
officer. The left security officer and the right security officer design these subsets to ensure that
operators only have access to their own traffic data, that is, by specifying particular profiles
(which give access only to particular message partners, exit points, and routing queues), units
and destinations. This feature is known as "Delegation" and supports the strict segregation of
traffic data between institutions required by a service bureau.

Activating Delegation
To activate the delegation feature, the following security configuration parameter must be set in
the Security Definition entity:
Restrict Delegation = Yes

72 Security Guide
User Management

When this security configuration parameter is set to Yes, a third tab labelled Delegations is
available to the left security officer and the right security officer in the selected Operator Details
window.
When the security configuration parameter is set to No, then the tab is not displayed and the
subset assignments are not available.
For an introduction to the service bureau, see the Getting Started guide.

The Delegations tab


The Delegation tabs purpose is to enable the left security officer and the right security officer to
specify which local security officer has access to which set of Operator Profiles, Units, or
Destinations.

Delegated profiles
The Available list contains operator profiles specifically created by the left security officer and
the right security officer to match the requirements of each participating SWIFT user. Operator
profiles considered suitable for a particular local security officer to administer are moved from
the Available to the Selected list. The operator profiles must be prefixed with the address of
the institution. For example, institution ABNKBEBB has two separate message preparation roles
ABNKBEBB_MPA1 and ABNKBEBB_MPA2.

Delegated units
Units considered suitable for a particular local security officer to administer are moved from the
Available to the Selected list. As individual messages can be assigned to units, only operators
who belong to the same unit can display or modify the message. Delegating access to units
therefore provides a method of controlling which operators can access which messages.

Note Units are not applicable for CRnet message traffic.

Delegated destinations
Destinations considered suitable for a particular local security officer to administer, are moved
from the Available to the Selected list. The local security officer can create or modify operator
profiles using only the own destinations selected here. If an attempt is made to save a profile
with a destination that is not specified here, then it is refused.
Entities that specify own destinations in their permission details windows are:

Application Interface

Message Creation

Message Modification

Message Approval

Relationship Management

SWIFT Interface

SWIFT Support

SWIFTNet Interface

27 March 2015 73
Alliance Access 7.1 on Alliance Web Platform

6.7 Profiles in a Sample Service Bureau


Example
The following is an example of a service bureau called "BizConnect" that serves two SWIFT
user institutions. These institutions are ABNKBEBB and INSTBEBB. Note that the operator
profiles, operator names, and unit names are all prefixed by the names of the corresponding
institutions.

Defined Operator Profiles

ABNKBEBB ABNKBEBB_MPA1

ABNKBEBB_MPA2

ABNKBEBB_MXA

INSTBEBB INSTBEBB_MPA

INSTBEBB_MXA

Defined Units

ABNKBEBB ABNKBEBB_DPT1

ABNKBEBB_DPT2

INSTBEBB INSTBEBB_DPT1

INSTBEBB_DPT2

INSTBEBB_DPT3

Using the profiles and units defined above, the LSO/RSO at BizConnect now delegates
operators, units and profiles according to the following diagram:

74 Security Guide
User Management

6.8 Operators and Users of Alliance Access


Introduction
This section outlines the default operators and users of Alliance Access, arranged by user
profile.

6.8.1 Alliance Administrator


Overview
Depending on your operating system, see "AIX, Linux, or Solaris User Accounts" on page 21 or
"Security on Windows Systems" on page 30 for information about this Alliance Access user.

6.8.2 Supervisor
Overview
Supervisors administer and configure Alliance Access, and perform sensitive operational duties,
such as archiving data. They also authorise messages during message preparation. Also,
Supervisors can verify outgoing SWIFT messages and authorise outgoing SWIFT messages.

Note This role is only relevant if your organisation is licensed to send and receive other
SWIFT message types as well as CRnet messages.

Supervisors are responsible for:

defining (but not approving) new operators

defining operator permissions and entitlements

defining and approving new units, and removing unapproved units only

defining and approving routing criteria

defining and approving routing schemas

defining batch input and output processing criteria

defining message partners

defining exit points

defining logical terminals

setting up emission and reception profiles for MX messages

configuring system parameters, such as date and time formats

defining calendar details

scheduling automatic operations, such as backing up or archiving

verifying and authorising messages

monitoring and archiving the Event Log and Message File

completing, moving, reactivating, reassigning, and changing the priority of message


instances

27 March 2015 75
Alliance Access 7.1 on Alliance Web Platform

backing up Alliance data and archives (using System Management entity facilities)

updating the Correspondent Information File (CIF), both by installing a Bank File and by
making manual updates
A default operator profile called R7.1_Supervisor is provided within Alliance Access. This
profile gives the entitlements and permissions to perform the duties described above. This
profile may be changed, if required. For details about this profile, see "Default Operator Profiles"
on page 84. Note that this profile does not provide access to normal operational functions
relating to the creation or the modification of messages.

6.8.3 Relationship Management Application Administrator


Overview
The main responsibilities include:

activating authorisations

revoking authorisations

accepting authorisations

rejecting authorisations

cleaning up the data store


A default operator profile called R7.1_RMA_Admin is provided within Alliance Access, which
provides the functionality described above. This profile may be changed, if required. For details
about this profile, see "Default Operator Profiles" on page 84.

6.8.4 Relationship Management Application Operator


Overview
The main responsibilities include:

viewing authorisations

printing authorisations

creating authorisations

creating and modifying comments to authorisations

sending queries about authorisations and business relationships

responding to queries about authorisations and business relationships


A default operator profile called R7.1_RMA_Oper is provided within Alliance Access, which
provides the functionality described above. This profile may be changed, if required. For details
about this profile, see "Default Operator Profiles" on page 84.

76 Security Guide
User Management

6.8.5 SWIFT Operator


Overview
The role of the operator in Alliance Access is centred on the processing of messages into, and
out of, Alliance Access. No access is allowed to security-related functions, and all message-
related configuration is deemed to have been managed correctly by supervisory users. An
operator can view, but not normally alter, information about the configuration of the system.

Note This role is only relevant if your organisation is licensed to send and receive other
SWIFT message types as well as CRnet messages.

Two specific types of operator are recognised in Alliance Access:

those concerned only with SWIFTNet access and the processing of messages between
Alliance Access and back-office systems. These operators do not require access to the day-
to-day message processing functions

those concerned with the actual creation, verification, and modification of incoming and
outgoing messages within Alliance Access

The main responsibilities of the operator include

adding or modifying correspondent and alias details in the Correspondent Information File
(CIF)

printing currency and country details from the CIF

starting, running, and stopping sessions for batch input or output

starting, running, and stopping sessions for interactive message exchange with other
systems
A default operator profile called R7.1_Operator is provided within Alliance Access, which
provides the functionality described above. This profile may be changed, if required. For details
about this profile, see "Default Operator Profiles" on page 84.
A separate profile, called R7.1_MsgEntry is also provided. This gives operators entitlements to
the message preparation functions, including:

creating SWIFT user messages and system messages of any type

modifying incoming and outgoing messages, except for messages in the Emission Security
Modification queue or Reception Security Modification queue

verifying messages created by other operators

bypassing verification and authorisation of newly created SWIFT messages

completing (that is, discarding) messages in the Text Modification queue


This profile may be changed, if required. For details about this profile, see "Default Operator
Profiles" on page 84.

27 March 2015 77
Alliance Access 7.1 on Alliance Web Platform

6.8.6 Application User


Overview
The Application User, who can log on using either operational or housekeeping mode, can
perform the following duties:

exporting and importing of configuration data

managing entities

monitoring entities

downloading files in real time


For more information about these actions, see the Administration Guide for AIX, Linux, Oracle
Solaris, or Windows.
For details about the R7.1_Import_Export profile, which is associated with this user, see
"Default Operator Profiles" on page 84.

6.8.7 CRnet Supervisor


Responsibilities
CRnet Supervisors are responsible for managing day-to-day communications between their
institution and the Host services.
The main responsibilities include:

starting and stopping the CRnet component

opening and closing secure sessions with the Host System

holding and releasing message queues

configuring the Host services (although this is more usually the responsibility of the system
administrator)

configuring customer applications (again, this is usually the System Administrator's


responsibility)

monitoring CRnet message traffic

investigating CRnet-related events in the Event Journal

examining CRnet message details in the Message File

6.8.8 CRnet Workstation Operator


Facilities
Normally, a CRnet workstation operator does not need direct access to Alliance Access, and
only communicates with Alliance Access through the GUI installed on the workstation. The
workstation software communicates with Alliance Access, and uses the facilities provided by the
CRnet Interface application to exchange data with the host system.

Note For information about the facilities provided by the CREST GUI, refer to the user
guides published by Euroclear EUI.

78 Security Guide
User Management

6.8.9 MsgPartner Profile


Overview
The default R7.1_MsgPartner profile that is assigned to message partners sets no constraints
on the messages that can be created. This profile can be modified to suit your own business
needs. This profile is only used within the Application Interface to control the privileges granted
to an external message partner, when sending prepared messages which are then "created"
within Alliance Access. Human operators never use this profile.

6.9 Using Operator Profiles


Overview
All Alliance operators have operator profiles assigned to them as part of their operator definition.
Operator profiles define entitlements and permissions to use Alliance applications and functions.
Operator profiles are created and modified within the Security Definition entity. Each operator
profile defines:

the entities that an operator is allowed to use

the entitlements to use functions within a particular entity

the permissions associated with an entitlement, that is, the permitted scope of an operator's
actions when using a given entity function

Entitlements
The entitlements defined in an operator profile determine the nature of the windows, menus,
commands, and available choices which appear to an operator who is assigned that profile.
Entities and functions that are denied in an operator profile are not available when that operator
is signed on to Alliance.
An operator profile cannot be modified while it is in use, that is, if any operator who has been
assigned that particular profile is currently signed on. Any changes to an operator profile
automatically cause the operators that use it to become unapproved. Following such changes,
both security officers (or operators with the appropriate entitlement) must approve all operators
using that profile.

Assigning an Operator Profile


An operator profile can be created that is unique to a particular operator, or the same operator
profile can be assigned to several operators, depending upon their operational duties and
responsibilities.
Where two or more different profiles are assigned to the same operator, Alliance checks that
there is no conflict between the entitlements and the permissions in one profile and those in
another.

Note Within Alliance, the roles of left security officer and right security officer are pre-
determined, and both security officers have the same operator profile. This profile
cannot be viewed, modified, or removed.
"Default Operator Profiles" on page 84 details the various entitlements and
permissions assigned to the left security officer and the right security officer.

27 March 2015 79
Alliance Access 7.1 on Alliance Web Platform

Note An operator profile can be selected from the existing list of profiles (a maximum of
500 profiles are visible).

6.9.1 Entitlements and Permissions


Overview
When defining or modifying operator profiles, security officers (or privileged users) can select
which entities an operator is entitled to use. For each selected entity, the functions available
within that application appear. Those functions which an operator is entitled to use may be
selected, as required, according to the operational duties and responsibilities of that operator.
In addition, some functions have associated permissions which can be defined. These
permissions determine the scope of an operator's permitted actions within that function.
For example, within the Event Log entity, an operator can be assigned the "Archive" entitlement.
Within this entitlement, a separate permission must be granted if the operator is allowed to
schedule automatic archiving on a specific date and time.

Specific security officer entitlements


Security officers (left security officer and right security officer) have a specific set of entitlements
assigned to them by Alliance, and these cannot be changed. However, security officers can
assign virtually any entitlement or permission to other operators (including those functions
denied to security officers).
All security-related functions of the security officers can be assigned to other operators, except
for the entitlement to reset the other security officer's password, and the entitlement to modify
security parameters. Most of the security parameters relate to password control. These two
entitlements are unique to the left security officer and the right security officer, and cannot be
assigned to other operators.

6.10 Definition of Units and Restrict Functions


Definition of units in Alliance Access
You can use Alliance Access to add, modify, or remove units. After a new unit has been added,
an operator or a security officer must approve the unit before it can be used with operators. The
maximum number of units that can be assigned to an operator is 200.
The use of units makes it easy to divide message processing tasks between different groups of
operators. Operators can be members of units. Incoming and outgoing messages can be
assigned to units.

Note Units are not applicable for CRnet (CREST) message traffic.

Operator Restrict functions


Security officers can use the Restrict Functions security parameter (Operator class) to specify
whether an operator can perform operator-related actions on operators belonging to any unit, or
only on operators that belong to a subset of the same units as the operator performing the
action. The default is No, which means that an operator with the correct entitlements can open,
print, add, modify, approve, or remove operators belonging to any unit. If the parameter is set to
Yes, then an operator can only use these functions on operators that belong to a subset of the
same units as the operator performing the action. The setting of this parameter does not affect

80 Security Guide
User Management

the left security officer and right security officer, which always have unrestricted access to
operator functions.
If the parameter is set to Yes, then the following restrictions apply:

The operator carrying out operator-related functions can only assign a subset of the units
assigned to himself, to another operator.

An operator A can only display information and use operator-related functions on another
operator B, if the set of units assigned to operator B is a subset of the units assigned to the
operator A.
For example, if operator Marc belongs to units A, B and C, and operator Luc belongs to units
C and D, neither Marc or Luc can display each other's operator details. Operator Dirk, who
belongs to units A, B, C, and D, can display the operator details for both Marc and Luc and
use operator-related functions on them. However, neither Marc or Luc can display Dirk's
operator details.

Note When the security parameter Restrict Delegation is set to Yes, any profile
assignments made for units take precedence. This does not affect the left security
officer and right security officer.

6.11 Authentication Server Groups and One-Time


Passwords
Description
An authentication server cannot differentiate between different operators who are defined with
the same name on different Alliance Access (or even Alliance Gateway) instances. Therefore,
operators must have a unique name over the different instances, or each instance must have its
own dedicated authentication server.
Because the left security officer, the right security officer, or any other operator that is defined
for using one-time passwords can no longer sign on if Alliance Access cannot connect to the
authentication server (thereby rendering Alliance Access inaccessible), you must not define all
your operators (including LSO and RSO) as needing one-time passwords.
This can be achieved in the following ways:

Define two operators as not using one-time passwords, one having the "Approve Operator -
Approve Left" and the other having the "Approve Operator - Approve Right" permission.
These operators can then reset the operators that are defined for one-time passwords to user
password mode, so that normal business can be resumed.

Define a number of operators defined as not using one-time passwords that are capable of
performing day-to-day activities (such as logging on to the SWIFT network).

Keep the Sec Officer One Time Pwd parameter set to No (that is, the left security officer
and the right security officer do not use one-time passwords).

27 March 2015 81
Alliance Access 7.1 on Alliance Web Platform

Both Alliance Access and the authentication server group have a policy concerning the
maximum number of consecutive wrong passwords before an operator is disabled:

The configured maximum number of consecutive wrong passwords must be the same on
both Alliance Access and the authentication server group.

If you have to enable an Alliance Access operator after the operator is disabled because of
using a wrong password, then the number of consecutive wrong passwords for this operator
must be reset on the authentication server at the same time.

Note If the authentication server group is unavailable or badly configured, then every
attempt to log in as LSO or RSO with an OTP password will be counted as a failed
password attempt, even if the password is the correct one. As fallback, Alliance
Access will check against the LSO and RSO private password in case of OTP error
at login, other than invalid password. An event 2235 will be logged in case of
successfull check. The LSO and the RSO operator must be careful to not try the
OTP password too often before they try their private password, otherwise their
account will become time-disabled and their private password will also be rejected.
If the LSO or the RSO operator account becomes time-disabled, then you must
wait 10 minutes before trying to re-enter the password.

For information about defining operators, see the Configuration Guide. For information about
configuring the authentication server group, see the Configuration Guide.

6.12 Password Controls


Introduction
Passwords are the primary means by which access to the system, its resources, and its data is
controlled.

6.12.1 Choice of Passwords


Overview
As mentioned previously, the use of confidential passwords provides the best means by which
software access can be denied to fraudulent users.
Regular password renewal helps prevent others from discovering a password. Of equal
importance is the nature of the passwords themselves. Due consideration must be given to the
choice of password strings to ensure that they are not easily guessed or discovered.

Password criteria
It is very easy to pick a password others can easily deduce. Your nickname, middle name, your
wife's or husband's name, or your pet's name must not be considered to be "secret" information.
Such choices produce very weak passwords. Easy key patterns, such as six adjacent keys on
the keyboard, are equally easy to deduce when used as passwords.
While Alliance Access provides some controls over the choice of passwords (for example,
minimum length, password history, illegal characters), all users must be encouraged to select
passwords that cannot easily be discovered.
For example, a password must not be:

the name of a person, or pet

82 Security Guide
User Management

the name of a place, or town

the name of a system, or application

any whole word that can be found in a dictionary


Good passwords:

contain a mixture of both lower-case and upper-case characters

contain numbers as well as letters

must not consist of the same sequence of characters repeated two or more times - for
example, users must not use passwords such as swiftswift.

are easily remembered

are quick and convenient to type


A good way to produce a memorable password is to combine the first letters of the title of a
favourite book or film with a number.
Operators who require access to different systems must ensure that they use different
passwords on each system. In this way, if one password is discovered, the integrity of only one
system is compromised.
User passwords must never, if at all possible, be written down on paper. To do so implies that
the password cannot easily be remembered. Passwords that have to be recorded, must be
done so in a way that does not reveal the value of the password (for example, by transposing
alternate characters).
If an operator forgets a password, then that password must be reset by security officers and the
user encouraged to select a more memorable password.
SWIFT recommends that all passwords are a minimum of six characters in length and that
operator passwords are renewed at least every three months.

6.12.2 Password Encryption


Overview
All operator passwords used in Alliance Access are stored in an encrypted form. A digest
calculation using the SHA-256 algorithm is performed using the following input data: operator
nickname, operator password, and salt. The salt is a random value that is re-generated at
each password modification. Both the salt and digest are stored encrypted in the database
using the Advanced Encryption Standard (AES) encryption algorithm.

27 March 2015 83
Alliance Access 7.1 on Alliance Web Platform

7 Default Operator Profiles

7.1 Overview of Default Operator Profiles


Introduction
The tables in this section show the various entitlements and permissions for the default profiles,
which are provided as standard with Alliance Access.

Differences in operator permissions between Alliance Access (Alliance Web Platform) GUIs
and Alliance Workstation
Operator permissions behave differently on the Alliance Access (Alliance Web Platform) GUI
packages versus Alliance Workstation.
For example, for the Hold Queue or Release Queue action, two permissions exist: one in the
System Management Application and another in the Monitoring application On Alliance
Workstation, these actions will check which application you are connected to and verify if your
operator profile has the permission to perform that action for that application. On the other hand,
if you are using the Alliance Access Configuration or Monitoring GUI (on the Alliance Web
Platform), you will be allowed to hold or release the queue if your operator profile has either of
the following actions: Monitoring / Hold Queue or System Management / Hold Queue. This
means that, on the Alliance Web Platform, the actions a user is entitled to perform is more
entity-based. For example, if you have the permission to hold or release a queue, you inherit
this permission in any Alliance Web Platform GUI package where this action is present.

R7.1_Superkey
The default R7.1_SuperKey profile is associated with the Alliance Access Administrator, which
gives the administrator access to all licensed Alliance Access entities. The Administrator can
use the same application functions as a Supervisor, and is additionally able to create, verify,
authorise, or modify messages.

R7.1_Supervisor
The default R7.1_Supervisor profile is associated with the Alliance Access Supervisor. If an
operator is assigned the R7.1_Supervisor profile, then this gives the operator access to all
standard Alliance Access applications.

R7.1_Operator
The default R7.1_Operator profile enables an Alliance Access operator to sign on to the SWIFT
network and process messages passing between Alliance Access and other systems.

R7.1_MsgEntry
The default R7.1_MsgEntry profile enables an Alliance Access operator to create and process
messages within Alliance Access, but in itself does not allow the operator to connect to the
SWIFT network or to control the message flow.
The R7.1_MsgEntry profile is designed to be used in combination with other profiles, and not
on its own. If you want to use the R7.1_MsgEntry profile, then you must ensure that a profile
that has access to the Access Control application (for example, the R7.1_Operator profile) is
also assigned in the "operator definition".

84 Security Guide
Default Operator Profiles

R7.1_MsgPartner
The default R7.1_MsgPartner profile that is assigned to message partners sets no constraints
on the messages that can be created. This profile can be modified to suit your own business
needs. This profile is only used within Application Interface to control the privileges granted to
an external message partner, when sending prepared messages that are then "created" within
Alliance Access. Human operators never use this profile.

R7.1_Import_Export
The default R7.1_Import_Export profile contains the permissions required to export and import
configuration data using the Configuration Replication tools. You can assign this profile to the
software owner (all_adm) by using the Software Owner Profile security parameter. If you do
not assign this profile to the software owner, then you must run the tools with the -user, or
-application, and -password options, to provide the user credentials.
For more information about the Configuration Replication tools, see the Administration Guide for
AIX, Linux, Oracle Solaris, or Windows.

R7.1_RMA_Oper and R7.1_RMA_Admin


The default R7.1_RMA_Oper and R7.1_RMA_Admin profiles provide entitlements for using the
Relationship Management application in Alliance Access. These profiles are designed to be
used with other profiles, and not on their own. For a user to use the Relationship Management
application, you must ensure that a profile that has access to the Access Control application (for
example, the R7.1_Operator profile) is also assigned in the operator definition. The RMA_Oper
and RMA_Admin entitlements and permissions are described in the following table.
Users with the R7.1_RMA_Oper profile have permission to view, print, create, modify, and add
comments to authorisations. In addition, they have permission to send and respond to queries
about authorisations and business relationships. However, the R7.1_RMA_Oper profile does
not grant users the entitlements for functions that affect the active (or "live") authorisation, such
as activating authorisations, revoking, accepting, rejecting them, or for cleaning up the
database. Users with the R7.1_RMA_Admin profile can perform those actions. The
permissions in both default profiles include the four-eyes principle by default, because the
Bypass approval permissions are set to "No". This means that one user must approve the
actions of another user.
For more information about relationship management, see the Relationship Management Guide.

R7.1_RMA_Admin: The role of the Relationship Management Application (RMA)


Administrator is to manage the authorisations and query messages in the Relationship
Management data store. Although a Relationship Management Application Administrator
cannot create or modify authorisations, a Relationship Management Application Administrator
can verify and authorise outgoing messages prepared by others. Alliance Access includes a
default operator profile, R7.1_RMA_Admin, to provide access to the functionality required by
an RMA Administrator.

R7.1_RMA_Oper: The role of the Relationship Management Application (RMA) Operator is


to create or modify an authorisation that allows a correspondent to send messages to your
institution. An RMA Operator does not have the permissions, by default, to perform other
tasks related to authorisation management (such as accept, reject, revoke, and so on). The
default profile R7.1_RMA_Oper is associated with the RMA Operator.

R7.1_IPLA_Oper
The ipla_admin tool command-line syntax can include the name of an Alliance Access
operator, depending on the action being performed. Alliance Access provides a default operator
profile for Integration Platform, to include any relevant applications and functions. Customers

27 March 2015 85
Alliance Access 7.1 on Alliance Web Platform

can assign that profile to an operator defined for use with the ipla_admin tool to ensure that
any relevant entitlements are present.

R7.1_IPLA_Monitor
This profile contains entitlements that provide read-only access to Integration Platform-related
content in the Alliance Access Monitoring GUI application.

Scope of entitlements
Although security officers do not have a configurable profile in the same way as other Alliance
Access operators, the scope of their functional entitlements is also shown in the following
tables, and may be contrasted with the various default profiles.

Conventions used in operator profile tables


The following conventions are used in the tables that outline the default entitlements for
operator profiles:

Entitlements for each application are listed by function.

Some functions have additional permissions, and these functions have an asterisk (*) after
their name in Alliance Access. The additional permissions are listed in the Specific
permissions column in the tables, and their default values are listed in the operator profile
columns.

A checkmark () or value in the column of an operator profile means that the operator profile
has entitlements to access or use the application or function.

A dash (-) in the column of an operator profile means that the operator has no entitlements to
access or use the application or function.

If an operator profile is not listed for an application, then it signifies that there are no default
entitlements for that profile.

For clarity, the 'R7.1_' prefix is omitted from the profile names in the headings of the tables.

7.2 Access Control Application


Description
The Access Control application controls all access to Alliance Access and, therefore, to all of
the other applications and functions.
The operator profile defines which applications that a user can use. A user cannot sign on to
Alliance Access unless the operator profile allows the user to use the Access Control
application. The LSO/RSO or System Administrator uses the Security Definition application to
define operator profiles.

Entitlements and permissions within the Access Control application

Entitlement Specific LSO/RSO Super Super- Import Operator IPLA_ IPLA_


permissions Key visor Export Oper Monitor

Open application None - -

Signon Start Time 1 0000 0000 0000 - 0000 0000 0000

End Time 1 2357 2357 2357 - 2357 2357 2357

86 Security Guide
Default Operator Profiles

Entitlement Specific LSO/RSO Super Super- Import Operator IPLA_ IPLA_


permissions Key visor Export Oper Monitor

Start Time 2 2358 2358 2358 - 2358 2358 2358

End Time 2 2359 2359 2359 - 2359 2359 2359

WS Session 0 0 0 - 0 0 0
Timeout 0

Bank Query None - - - -

Files on Server None - - - -

Embedded None - - - - -
Checks

Files on User None


Space

Run supportinfo None - - - - -

WS session None 0 0 - 0
timeout

7.3 Application Interface Application


Description
The Application Interface controls the transfer of messages and files between Alliance Access
and back-office applications, printers, or any other system that communicates with Alliance
Access. Suitable messages for transferring include SWIFT FIN, MX, FileAct, and system
messages. Suitable files include payload files, or files that contain several messages (such as
for Bulk Payments).
Within the Application Interface, a message partner represents the external application or
product that communicates with Alliance Access. A message partner profile specifies how each
message partner communicates with Alliance Access, and allows an entitled user to control and
monitor the communication sessions.
Alliance Access provides default message partner profiles and default exit points. These are
described in this section, as well as in the Default Printouts on the release media.
Alliance Access transfers a message to a message partner through an exit point, which holds
the message in a queue before transferring it to the message partner. Each exit point is
associated with a particular message partner.
The Application Interface allows the user to:

create, modify, or remove exit points and message partner profiles

assign an exit point to a message partner

control and monitor communication sessions between Alliance Access and a message
partner

Entitlements and permissions within the Application Interface application

Entitlement Specific permissions LSO/RSO Super Super- Import Operator Msg


Key visor Export Partner

Open Application None -

27 March 2015 87
Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific permissions LSO/RSO Super Super- Import Operator Msg


Key visor Export Partner

Abort Session Message Partner(s) - None None - None -


(Allowed/Prohibited) prohibited prohibited prohibited

Add Exit Point None - - -

Add Partner Local Authentication -


Key:
First part (Yes/No) - Yes Yes Yes - -

Second part (Yes/No) - Yes Yes Yes - -

Session -
Authentication Key:

First part (Yes/No) - Yes Yes Yes - -

Second part (Yes/No) - Yes Yes Yes - -

Access Message Own destination None None - - - None


prohibited prohibited prohibited

Create Message Own destination - None - - - None


(Allowed/Prohibited) prohibited prohibited

MT - None - - - None
(Allowed/Prohibited) prohibited prohibited

CCY+[AMOUNT] - None - - - None


(Allowed/Prohibited) prohibited prohibited

Service $ identifier(1) - None - - - None


(Allowed/Prohibited) prohibited prohibited

Dispose Message Bypass verify MT - 999 - - - None


(Allowed/Prohibited) allowed prohibited

Bypass verify CCY - None - - - None


(Allowed/Prohibited) prohibited prohibited

Bypass auth. MT - 999 - - - None


(Allowed/Prohibited) allowed prohibited

Bypass auth. CCY - None - - - None


(Allowed/Prohibited) prohibited prohibited

Bypass authorisation: - None - - - None


Service $ identifier(1) prohibited prohibited
(Allowed/Prohibited)

Bypass verification: - None - - - None


Service $ identifier(1) prohibited prohibited
(Allowed/Prohibited)

Enable Mess. None - - - -


Partner

Mod Exit Point None - - -

Mod Partner Local Authentication -


Key:
First part (Yes/No) - Yes Yes Yes - -

88 Security Guide
Default Operator Profiles

Entitlement Specific permissions LSO/RSO Super Super- Import Operator Msg


Key visor Export Partner

Second part (Yes/No) - Yes Yes Yes - -

Session -
Authentication Key:

First part (Yes/No) - Yes Yes Yes - -

Second part (Yes/No) - Yes Yes Yes - -

Move to Routing None - - - -


Point

Open/Print Exit Exit Points - None None None None -


Point (Allowed/Prohibited) prohibited prohibited prohibited prohibited

Open/Print Partner Local Authentication -


Key:

First part (Yes/No) - Yes Yes Yes No -

Second part (Yes/No) - Yes Yes Yes No -

Session -
Authentication Key:

First part (Yes/No) - Yes Yes Yes No -

Second part (Yes/No) - Yes Yes Yes No -

Message Partners - None None None None -


(Allowed/Prohibited) prohibited prohibited prohibited prohibited

Rem Exit Point None - - - -

Rem Partner Local Authentication -


Key:

First part (Yes/No) - Yes Yes - - -

Second part (Yes/No) - Yes Yes - - -

Session -
Authentication Key:

First part (Yes/No) - Yes Yes - - -

Second part (Yes/No) - Yes Yes - - -

Run Session Message Partner(s) - None None - None -


(Allowed/Prohibited) prohibited prohibited prohibited

Start Session Message Partner(s) - None None - None -


(Allowed/Prohibited) Prohibited prohibited prohibited

Stop Session Message Partner(s) - None None - None -


(Allowed/Prohibited) prohibited prohibited prohibited

(1) To include all message types for a service, you must specify a wildcard for the identifier. For example, swift.if%
$setr.003% or swift.generic!p$%, but not swift.generic!p.

27 March 2015 89
Alliance Access 7.1 on Alliance Web Platform

7.4 Calendar Application


Description
This application is used to create or modify calendars in Alliance Access. Once a calendar has
been set up, an operator can schedule certain actions to occur automatically, if the operator has
Store schedule permissions assigned for that action.
For example, Alliance Access stores details of the messages it sends and receives in a
Message File. Once a calendar is set up, an operator with Store schedule permissions can
schedule regular archiving of the Message File. This keeps the file from growing too large.

Entitlements and permissions within the Calendar application

Entitlement Specific permissions Super Supervisor


Key

Open Application None

Add Calendar None

Add Calendar Year None

Default Calendar Year None

Modify Calendar Year None

Open/Print Calendar None

Remove Calendar None

Remove Calendar Year None

7.5 Correspondent Information File Application


Description
The Correspondent Information File (CIF) contains essential data about a user's
correspondents, in the form of correspondent, alias, country, network, and currency records.
SWIFT also makes available an update file that contains details of all entries that have been
added, modified, or deleted since the last BIC was issued. This file can be used to update the
CIF.
Each correspondent record includes details such as the correspondent's BIC-11, name and
address, and so on. Country records include details of the 2-character country code and the
name of the country. Currency records include details of the 3-character currency code, the
name of the currency, and the number of decimal places used in the currency. Alias records
contain alternative names that you have defined for a correspondent or a group of
correspondents.
The CIF also contains information about the preferred network interface used to connect
Alliance Access with each correspondent. The network interface can be SWIFTNet, SWIFT, the
Application Interface, or OTHER.
When an MT message is prepared using the Message Creation or Message Modification ,
Alliance Access references the sender or receiver BIC and automatically takes values from the
CIF and includes them as default values in the message. This helps to speed up message
creation and reduce errors.

90 Security Guide
Default Operator Profiles

An entitled user can use the Correspondent Information File to update the CIF, either by
importing information from the Full Bank File, or from the Bank Update File (distributed monthly
by SWIFT), or by making changes manually.
An entitled user can use the to:

update the CIF from an Alliance Bank File

create, modify or remove the correspondent, alias, country, or currency records

Entitlements and permissions within the Correspondent Information File application

Entitlement Specific Super Super- Import_ Operator


permissions Key visor Export

Open Application None

Add Alias None -

Add Correspondent None -

Add Country None - -

Add Currency None - -

Install Bankfile Store schedule (Yes/ Yes Yes - -


No)

Modify operating Yes Yes - -


mode (Yes/No)

Modify Alias None -

Modify Corr Dets None


(Correspondent
details)

Modify Country None - -

Modify Currency None - -

Open/Print Alias None -

Open/Print Corr Dets None


(Correspondent
details)

Open/Print Country None -

Open/Print Currency None -

Remove Alias None - -

Remove None - -
Correspondent

Remove Country None - -

Remove Currency None - -

27 March 2015 91
Alliance Access 7.1 on Alliance Web Platform

7.6 CRnet Interface Application


Entitlements and permissions within the CRnet Interface application

Entitlement Specific permissions Super


Key

Open Application None

Add/Rem CRnet Rout. None

CRnet File Transfer None

CRnet Interactive None

Manage Secure Sess. None

7.7 Event Log


Description
All successful and unsuccessful actions performed by operators, and by the Alliance Access
system, are identified and recorded as events in the Event Log. This data provides a detailed
audit trail of all actions performed in Alliance Access.
Each record in the Event Log includes details of:

the date and time that the event occurred

the id of the operator (or system) that caused the event

the class and severity of the event. Events relating to the same area in Alliance Access are
grouped in a class. For example, all communication-related events belong to the
communication event class. The severity indicates the importance of an event. For example,
it is a more severe event if a message fails authentication than if an operator signs on.

a text description of the event


An LSO/RSO or entitled user can use the Event Log application for audit and investigation
purposes by searching the events stored in the Event Log based on a specific criterion. You can
then display or print the search results.
An LSO/RSO or entitled user can also use the Event Log application to archive events. You can
back up these archived events, which keeps the Event Log at a manageable size. If a calendar
has been set up, then you can use the Event Log application to schedule archiving to occur
automatically at specified times. Otherwise, you must archive manually.
Clearly, some events are more important than others. Alliance Access allows you to declare
certain events as alarms. Alarms can be displayed on-screen and distributed to a defined group
of operators and internal correspondents (through MT 999), for immediate action, or routed
outside Alliance Access (for example, to a file). The use of alarms ensures that supervisors or
other operators know very quickly if any unexpected user or system activity takes place.
The creation of an operator profile or an operator definition, or modification of an existing
definition, is also logged in the Event Log.
Alarms (or events configured as alarms) can also be sent to SNMP Manager applications (such
as HP OpenView or Tivoli products) so that third-party software can monitor them.

92 Security Guide
Default Operator Profiles

Entitlements and permissions within the Event Log application

Entitlement Specific permissions LSO/RSO Super Supervisor


Key

Open Application None

Archive Store schedule (Yes/No) - Yes Yes

Modify operating mode - Yes Yes


(Yes/No)

7.8 Integ. Platform Application


Description
This application defines access to Integration Platform data. It contains the following
entitlements:

Add/Rem Component, which allows the use of the ipla_admin -install,


ipla_admin -uninstall, and ipla_admin -remove commands. These commands
allow the addition or removal of the following kinds of configuration data that is used by
components deployed in IPLA:

Queues of type IPLA

Message processing functions

System configuration parameters

Security configuration parameters

Manage Component, which allows access to all actions available in the Integration Platform
node / Components and Integration Platform node / Details for Component <name>
pages in the Alliance Access Monitoring application.

Manage Integr. Data, which allows the use of the ipla_admin -data command-line tool to
enable the upload of Integration Platform-related integration data into Alliance Access.

Mon Bundle, which gives access to the Integration Platform node / Bundles page in the
Alliance Access Monitoring application and allows you to view the information that it contains.

Mon Component, which gives access to the Integration Platform node / Components page
in the Alliance Access Monitoring application. This entitlement allows you to open an object in
the list, but does not allow you to perform start or stop actions for components. It also gives
access to the Details for Component <name> page for the opened object and allows you to
open a Camel context to view the Camel routes for it. It does not allow you to start or stop
actions for Camel routes.

Entitlements and permissions within the Integ. Platform application

Entitlem Specific LSO/ Super Supervis Import Operator RMA IPLA_ IPLA_
ent permissi RSO Key or Export Admin Oper Monitor
ons

Add/Rem None - - - - - - -
Compone
nt

27 March 2015 93
Alliance Access 7.1 on Alliance Web Platform

Manage None - - - - - - -
Compone
nt

Manage None - - - - - - -
Integr.
Data

Mon None - - - - - -
Bundle

Mon None - - - - - -
Compone
nt

7.9 Message Approval Application


Description
Any MT message containing important data (such as an amount or a value date) must be
verified.
The Message Approval application allows an entitled user to:

display a list of the messages held in the Verification queue

select a specific message and display its details - any fields to be verified are highlighted, but
blank

re-enter the data for each verifiable field

send the message to another queue so that message processing can continue. A verified
message is usually routed to the Authorisation queue.
Messages must often be authorised before they can be released to the SWIFT network. The
Message Approval application is also used to authorise messages. Authorisation simply
involves giving the message a final visual check to ensure that it is accurate.
The Message Approval application allows an entitled user to:

display a list of the messages held in the Authorisation message queue

select a specific message and display its details, to check the validity of the fields

send an authorised message to the network specified queue. The relevant network interface
then automatically processes these messages.

Tip When messages are imported in the database using No Validation, the
keywords are not extracted. As a consequence, an operator that has permissions
restricted by certain keywords, such as CCY or Amount, can open messages in the
Verification and Approval queues even though those messages have values
outside the permitted range of values.

Entitlements and permissions within the Message Approval Application

Entitlement Specific permissions Super Supervisor Msg


Key Entry

Open Application None

94 Security Guide
Default Operator Profiles

Entitlement Specific permissions Super Supervisor Msg


Key Entry

Approve Message Own destination None None prohibited None prohibited


(Allowed/Prohibited) prohibited

Can Verify (Yes/No) Yes Yes Yes

Can Authorise (Yes/No) Yes Yes No

Verify own entered Mesg Yes No No


(Yes/No)

Auth. own entered Mesg Yes No No


(Yes/No)

Auth. own verified Mesg Yes No No


(Yes/No)

Can do Group Authorise/ Yes No No


Reject (Yes/No)

CCY/Amount None None prohibited None prohibited


(Allowed/Prohibited)(3) prohibited

Swift FIN User MT None None prohibited None prohibited


(Allowed/Prohibited) prohibited

Swift FIN System MT None None prohibited None prohibited


(Allowed/Prohibited) prohibited

Swift APC System MT None None prohibited None prohibited


(Allowed/Prohibited) prohibited

Service $ identifier (2) None None prohibited None prohibited


(Allowed/Prohibited) prohibited

trans App Limit


(Allowed/Prohibited)

Daily App Limit


(Allowed/Prohibited)

Final Approver
(Allowed/Prohibited)

Dispose Message(4) Bypass Authorisation for None - None prohibited


CCY/Amount prohibited
(Allowed/Prohibited)(3)

Bypass Authorisation for None - 999 allowed


Swift FIN User MT prohibited
(Allowed/Prohibited)

Bypass Authorisation, None None prohibited None prohibited


Service $ identifier(2) prohibited
(Allowed/Prohibited)

Own destination (1) None None prohibited None prohibited


(Allowed/Prohibited) prohibited

Route Message None - -


(1)
Own Destination None None prohibited None prohibited
(Allowed/Prohibited) prohibited

27 March 2015 95
Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific permissions Super Supervisor Msg


Key Entry

Treat Recovered Msg Own destination None None prohibited -


(Allowed/Prohibited) prohibited

Group Authorise (Yes/No) Yes Yes -

(1) You can use the underscore (_) wild card in any position in a BIC and it can be present multiple times in the same
BIC. The percent (%) wild card character is not permitted.

(2) To include all message types for a service, you must specify a wildcard for the identifier. For example, swift.if%
$setr.003% or swift.generic!p$%, but not swift.generic!p.

(3) Your permissions may not allow you to authorise a certain amount or currency, depending on the first occurrence
of the amount or currency. Keywords are always extracted from their first occurrence. In the case of repetitive sub-
sequences, only the value of the first occurrence is taken into account.

(4) Permission details are only checked when disposing a message to a queue other than Text Modification.

7.10 Message Creation Application


Description
This application provides all the functions necessary to create messages.
An entitled user can either create a completely new message, or open an existing template and
base the message on it.
The application allows an entitled user to:

open a template and base a new message on it

create a message by entering all its details in full

create a template, or modify or remove an existing template

send it to another message queue so that processing can continue

Entitlements and permissions within the Message Creation application

Entitlement Specific Super Supervisor Msg Import_


permissions Key Entry Export

Open None - -
Application

Add/Mod/Rem Own destination (1)(3) None - None prohibited None prohibited


(5)
Template prohibited
(Allowed/Prohibited)

User MTs None - None prohibited None prohibited


(Allowed/Prohibited) prohibited

System MTs None - None prohibited None prohibited


(Allowed/Prohibited) prohibited

APC MTs None - None prohibited None prohibited


(Allowed/Prohibited) prohibited

Service&Identifier - None - None prohibited None prohibited


MX messages prohibited

96 Security Guide
Default Operator Profiles

Entitlement Specific Super Supervisor Msg Import_


permissions Key Entry Export
(Allowed/Prohibited)

Service&Identifier - None - None prohibited None prohibited


File messages prohibited
(Allowed/Prohibited)

Create List of None None None prohibited -


Message OwnDestination (3)(5) prohibited prohibited
(Allowed/Prohibited)

Can create Yes - No -


broadcasting (Yes/
No)

CCY/Amount None - None prohibited -


(Allowed/Prohibited) prohibited

Swift FIN User MT None - None prohibited -


(Allowed/Prohibited) prohibited

Swift FIN System MT None - None prohibited -


(Allowed/Prohibited) prohibited

Swift APC System None - None prohibited -


MT prohibited
(Allowed/Prohibited)

Multiple Retrieval Yes - No -


Allowed for
SWIFTNet FIN
System Messages
(Yes/No)

Multiple Retrieval Yes - No -


Allowed for APC
System Messages
(Yes/No)

FIN-Copy Allowed Yes - No -


(Yes/No)

Service&Identifier - None - None prohibited -


MX messages(2) prohibited
(Allowed/Prohibited)

Service&Identifier - None - None prohibited -


File messages prohibited
(Allowed/Prohibited)

Dispose Bypass Verification None - None prohibited -


Message(4) CCY/Amount prohibited
(Allowed/Prohibited)
Bypass Authorisation None - None prohibited -
CCY/Amount prohibited
(Allowed/Prohibited)

Bypass Verification None - 999 allowed -


Swift FIN User MT prohibited
(Allowed/Prohibited)

Bypass Verification None - None prohibited -


Service & identifier prohibited

27 March 2015 97
Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific Super Supervisor Msg Import_


permissions Key Entry Export
(Allowed/Prohibited)

Bypass Authorisation None - None prohibited -


Swift FIN System MT prohibited
(Allowed/Prohibited)

Bypass Authorisation None - None prohibited -


Swift APC System prohibited
MT
(Allowed/Prohibited)

Own Destination(1) None - None prohibited -


(Allowed/Prohibited) prohibited

Bypass authorisation: None - None prohibited -


service $ identifier(2) prohibited
(Allowed/Prohibited)

Route Message Own Destination (1) None - - -


(Allowed/Prohibited) prohibited

Change Exit Points None - None prohibited -


Network prohibited

(1) You can use the underscore (_) wild card in any position and it can be present multiple times. The percent (%) wild
card character is not permitted.
(2) To include all message types for a service, you must specify a wildcard for the identifier. For example, swift.if%
$setr.003% or swift.generic!p$%, but not swift.generic!p.
(3) BICs of up to 11 characters are supported.
(4) Permission details are only checked when disposing a message to a queue other than Text Modification.
(5) When deciding which Logical Terminal and Institution to display, both Create Message/Own Destination and Add/
Mod/Rem Template/Own Destination are taken into account. These permissions are merged together. In order to
properly limit the Own Destination action, the same BIC must be defined for both permissions as either BIC-8 or
BIC-11.

7.11 Message Modification Application


Description
Messages that fail validation during message creation, or that fail verification or authorisation,
can be sent to a Text Modification message queue for later editing. Alliance Access itself sends
any messages that are NAKed by SWIFT to this queue. Incoming and outgoing messages that
Alliance Access cannot process automatically are sent to other message modification queues.
An entitled user can use the Message Modification to edit the messages in these queues.
It allows an entitled user to:

select one of several message modification queues and display a list of the messages held in
it

select a specific message and review its contents

make changes to a message - the changes that can be made depend on the modification
queue that the message is in

98 Security Guide
Default Operator Profiles

send a modified message to the appropriate queue so that processing continues

Entitlements and permissions within the Message Modification application

Entitlement Specific permissions Super Key Msg Entry

Open Application None

Bypass Security None -

Complete Message (that is, None


discard the message)

Own Destination (1) None prohibited None prohibited


(Allowed/Prohibited)

Dispose Message(3) Bypass Verification CCY/ None prohibited None prohibited


Amount
(Allowed/Prohibited)
Bypass Authorisation CCY/ None prohibited None prohibited
Amount
(Allowed/Prohibited)

Bypass Verification Swift FIN None prohibited 999 allowed


User MT
(Allowed/Prohibited)

Bypass Verification Service & None prohibited None prohibited


identifier
(Allowed/Prohibited)

Bypass Authorisation Swift FIN None prohibited 999 allowed


User MT
(Allowed/Prohibited)

Bypass Authorisation Swift FIN None prohibited None prohibited


System MT
(Allowed/Prohibited)

Bypass Authorisation Swift None prohibited None prohibited


APC System MT
(Allowed/Prohibited)

Own Destination (1) None prohibited None prohibited


(Allowed/Prohibited)

Bypass authorisation: service None prohibited None prohibited


$ identifier(2)
(Allowed/Prohibited)

Modify Message Own destination Allowed/ None prohibited None prohibited


Prohibited

Mod. in Text_modification Yes Yes


queue (Yes/No)
Mod. in Emission_security Yes No
queue (Yes/No)

Mod. in Transmission_modif Yes Yes


queue (Yes/No)

Mod. in modif_after_recept Yes Yes


queue (Yes/No)

27 March 2015 99
Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific permissions Super Key Msg Entry

Mod. in Reception_security Yes No


queue (Yes/No)
CCY/Amount None prohibited None prohibited
(Allowed/Prohibited)

Swift FIN User MT None prohibited None prohibited


(Allowed/Prohibited)

Swift FIN System MT None prohibited None prohibited


(Allowed/Prohibited)

Swift APC System MT None prohibited None prohibited


(Allowed/Prohibited)

Multiple Retrieval Allowed for Yes Yes


FIN System Mesg (Yes/No)

Multiple Retrieval Allowed for Yes Yes


APC System Mesg (Yes/No)

FIN-Copy Allowed (Yes/No) Yes Yes

Service $ identifier(2) None prohibited None prohibited


(Allowed/Prohibited)

Route Message None -

Own Destination (1) None prohibited None prohibited


(Allowed/Prohibited)

Change Network Exit Points None prohibited None prohibited

(1) You can use the underscore (_) wild card in any position in a BIC and it can be present multiple times in the same
BIC. The percent (%) wild card character is not permitted.

(2) To include all message types for a service, you must specify a wildcard for the identifier. For example, swift.if%
$setr.003% or swift.generic!p$%, but not swift.generic!p.
(3) Permission details are only checked when disposing a message to a queue other than Text Modification.

7.12 Message File Application


Description
This application provides a central query, maintenance, and archiving facility for all messages
processed by Alliance Access.
When a message is created within Alliance Access, received from a message partner, or
received from the SWIFT network, it is known as the original instance. There is only one original
instance.
During message processing, Alliance Access routes the original message instance from one
message queue to another. Any number of copy or notification instances may be created as a
result of routing rules, and processed entirely separately from the original instance. For
example, Alliance Access may create a copy instance for every original instance sent to the
SWIFT network, and send the copy instance to a printer.
A notification instance is a report on the result of the processing performed on an original
instance or copy instance, and is usually sent to the sender of the message. For example, a
notification instance may report that the message failed authentication.

100 Security Guide


Default Operator Profiles

Collectively, the original instance and any copy and notification instances make up the
message.
The Message File stores all message instances. It also keeps a history of Alliance Access
message processing, whether related to communication with an external network or with
internal applications (transmission interventions), or to processing by an operator (user
interventions). The network header and message text information are common to all instances
of a message. Operator and transmission interventions are particular to an instance, and are
appended to the instance.
All instances (originals, copies, and notifications) must be completed before the message itself
is considered to be completed.
The LSO/RSO or other entitled user uses the Message File application to:

create duplicates of a message during message processing

investigate message processing by searching the message instances stored in the Message
File. You can then display or print the search results.

complete a message instance, or, if necessary, reactivate a completed message instance.


You can also move, reassign, or change the priority of a message instance. For example,
you may want to reactivate an instance because a system problem prevented it from being
processed normally.

archive messages. You can back up these archived messages, which keeps the Message
File at a manageable size. If a calendar has been set up, then you can use the Message File
application to schedule archiving to occur automatically at specified times. Otherwise, you
must archive manually.

create search templates

Entitlements and permissions within the Message File application

Entitlement Specific LSO/RSO Super Supervisor


permissions Key

Open Application None

Archive Store schedule (Yes/ - Yes Yes


No)

Modify operating - Yes Yes


mode (Yes/No)

Cancel msg emission Own Destination - None prohibited -


(Allowed/Prohibited)

Change expiry d/t Own Destination - None prohibited -


(Allowed/Prohibited)

Change priority Own Destination (1) - None prohibited None prohibited


(Allowed/Prohibited)

Complete Instance Own Destination (1) - None prohibited None prohibited


(Allowed/Prohibited)

Count Completely hide (No) (No) (No)


messages of other
units (Yes/No)

Own Destination (2) None prohibited None prohibited None prohibited


(Allowed/Prohibited)

27 March 2015 101


Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific LSO/RSO Super Supervisor


permissions Key

Move Instance Own Destination (1) - None prohibited None prohibited


(Allowed/Prohibited)

Re-activate Instance Own Destination (1) - None prohibited None prohibited


(Allowed/Prohibited)

Re-assign Instance Own Destination (1) - None prohibited None prohibited


(Allowed/Prohibited)

Search Completely hide No No No


messages of other
units (Yes/No)
Own Destination (2) None prohibited None prohibited None prohibited
(Allowed/Prohibited)

(1) You can use the underscore (_) wild card in any position in a BIC and it can be present multiple times in the same
BIC. The percent (%) wild card character is not permitted.

(2) You cannot use wildcards.

7.13 Monitoring Application


Description
The LSO/RSO or other entitled user uses the Monitoring application to monitor the Alliance
Access system and ensure that it is running smoothly. This application provides a continually
updated status for various Alliance Access 'objects', such as message queues, events, and
processes.
How you use Monitoring depends on your role. As a Security Officer, you may want to know
which operator is using which application. On the other hand, a user responsible for sending
and receiving messages may want to check how many messages are building up in the various
message queues.
Certain object states are considered as exceptional. For example, if the number of messages in
a message queue exceeds a user specified limit (threshold), then the message queue is in an
exceptional state. Monitoring can be set to notify you automatically whenever an object goes
into an exceptional state, so that you can resolve the problem as soon as possible.
If problems develop, then you can also use Monitoring to hold or release message queues, or
stop processes.

Entitlements and permissions within the Monitoring application

Entitlement Specific LSO/RSO Super Super- Operator


permissions Key visor

Open Application None -

Abort File Transfer None -

Hold Queue None -

Release Queue None -

Reset EProf Counter None -

Reset LT Counter None -

102 Security Guide


Default Operator Profiles

Entitlement Specific LSO/RSO Super Super- Operator


permissions Key visor

Reset MP Counter None -

Reset RProf Counter None -

Stop Process None - -

7.14 Relationship Management Application


Description
The SWIFTNet Public Key Infrastructure provides authentication for FIN messages using PKI-
based digital signatures. SWIFTNet Public Key Infrastructure does not provide a way to manage
the business relationships between the institutions that have pre-agreements for exchanging
messages.
The Relationship Management service and the Relationship Management functionality in
Alliance Access allow institutions to manage business relationships with their counterparties. An
authorisation process ensures that only authorised institutions can send messages to another
institution. With SWIFTNet Public Key Infrastructure, the FIN message can only be sent if the
receiver has authorised the sender to send a message.

Relationship Management authorisations


When one party in a business relationship consents to receive messages from a specific
correspondent, that consent is recorded in an Authorisation in the Relationship Management
Application (RMA). This application allows an entitled user to create and manage the
authorisations that restrict the sending of messages between parties in a business relationship.
Therefore, a correspondent can send an entitled user messages only when the entitled user has
authorised the correspondent to do so.
An authorisation is represented by different names in the Relationship Management Application
of each party. When an entitled user authorises a correspondent to send him messages, the
entitled user creates an Authorisation to Receive, which is represented as an Authorisation to
Send in the correspondent's system.
An authorisation can have a new version in preparation, which can be reviewed and changed by
different operators until it becomes enabled and is made the active version.

Entitlements and permissions within the Relationship Management application

Entitlement Specific Super RMA_ RMA_ Import_


permissions Key Admin Oper Export

Open Application None -

Accept Auth Own None prohibited None prohibited - -


Destination(s)
(Allowed/
Prohibited)

Services None prohibited None prohibited - -


(Allowed/
Prohibited)

Bypass Approval No No - -
(Yes/No)

27 March 2015 103


Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific Super RMA_ RMA_ Import_


permissions Key Admin Oper Export

Answer Message Own None prohibited None prohibited None prohibited None prohibited
Destination(s)
(Allowed/
Prohibited)

Services None prohibited None prohibited None prohibited None prohibited


(Allowed/
Prohibited)

App Granularity None - -


Dest

Approve Auth Own None prohibited None prohibited - -


Destination(s)
(Allowed/
Prohibited)

Services None prohibited None prohibited - -


(Allowed/
Prohibited)

Approve own No No - -
Actions
(Yes/No)

Approve Create Yes Yes - -


(Yes/No)

Approve Revoke Yes Yes - -


(Yes/No)

Approve Accept Yes Yes - -


(Yes/No)

Approve Reject Yes Yes - -


(Yes/No)

Approve Delete Yes Yes - -


(Yes/No)

Clean up Auth None - -

Create Auth Own None prohibited - None prohibited None prohibited


Destination(s)
(Allowed/
Prohibited)

Services None prohibited - None prohibited None prohibited


(Allowed/
Prohibited)

Bypass Approval No - No No
(Yes/No)

Def Granularity None - -


Dest

Def Signing BIC None - -


T&T

Delete Auth Own None prohibited None prohibited - -


Destination(s)

104 Security Guide


Default Operator Profiles

Entitlement Specific Super RMA_ RMA_ Import_


permissions Key Admin Oper Export
(Allowed/
Prohibited)
Services None prohibited None prohibited - -
(Allowed/
Prohibited)

Bypass Approval No No - -
(Yes/No)

Delete Query/ Own None prohibited None prohibited - -


Answer Destination(s)
(Allowed/
Prohibited)

Services None prohibited None prohibited - -


(Allowed/
Prohibited)

Export Auth Own None prohibited None prohibited - -


Destination(s)
(Allowed/
Prohibited)
Services None prohibited None prohibited - -
(Allowed/
Prohibited)

Store Schedule Yes Yes - -


(Yes/No)

Modify Operating Yes Yes - -


Mode
(Yes/No)

Export on None - -
Change

Import Auth Own None prohibited None prohibited - -


Destination(s)
(Allowed/
Prohibited)

Services None prohibited None prohibited - -


(Allowed/
Prohibited)

Store Schedule Yes Yes - -


(Yes/No)

Modify Operating Yes Yes - -


Mode
(Yes/No)

Mark Obsolete None - -


Auth(1)

Mod Signing BIC Own None prohibited None prohibited - -


T&T Destination(s)
Allowed/
Prohibited

27 March 2015 105


Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific Super RMA_ RMA_ Import_


permissions Key Admin Oper Export

Modify Auth Own None prohibited - None prohibited None prohibited


Destination(s)
(Allowed/
Prohibited)

Services None prohibited - None prohibited None prohibited


(Allowed/
Prohibited)

Bypass Approval No - No No
(Yes/No)

Open/Print Auth Own None prohibited None prohibited None prohibited None prohibited
Det Destination(s)
(Allowed/
Prohibited)
Services None prohibited None prohibited None prohibited None prohibited
(Allowed/
Prohibited)

Query Message Own None prohibited None prohibited None prohibited None prohibited
Destination(s)
(Allowed/
Prohibited)
Services None prohibited None prohibited None prohibited None prohibited
(Allowed/
Prohibited)

Reject Auth Own None prohibited None prohibited - -


Destination(s)
(Allowed/
Prohibited)
Services None prohibited None prohibited - -
(Allowed/
Prohibited)

Bypass Approval No No - -
(Yes/No)

Revoke Auth Own None prohibited None prohibited - -


Destination(s)
(Allowed/
Prohibited)

Services None prohibited None prohibited - -


(Allowed/
Prohibited)

Bypass Approval No No - -
(Yes/No)

Treat Query/ Own None prohibited None prohibited None prohibited -


Answer Destination(s)
(Allowed/
Prohibited)

106 Security Guide


Default Operator Profiles

Entitlement Specific Super RMA_ RMA_ Import_


permissions Key Admin Oper Export

Services None prohibited None prohibited None prohibited -


(Allowed/
Prohibited)

(1) This parameter is only applicable for users of the Relationship Management package on the Alliance Web
Platform.

7.15 Reporting Application


Description
The Reporting application entitles the user to use the Operational Reporting licensed option. It
provides access to all of the Reporting functions, such as activating Reporting, running reports,
deleting report runs, purging message data, and so on.
There are no default entitlements for the Reporting application.

7.16 Routing Application


Description
Although the flow of messages (routing) within Alliance Access is totally user configurable,
Alliance Access is shipped with a pre-defined routing schema which controls this flow.
The routing schema consists of a series of routing points. Each routing point consists of:

a message queue, where message instances accumulate

a processing function, which processes message instances from the queue and may create
new message instances, copies, or notifications.

a set of routing rules, which are used to determine the onward flow of each message
instance (for example, to another routing point, to the SWIFT network, or to an exit point such
as a link to a printer)
An LSO/RSO or other entitled user can use Routing to:

create, duplicate, modify, or remove routing schemas, routing rules, and keywords

activate a specific routing schema - this becomes the schema that Alliance Access uses to
route messages.

Entitlements and permissions within the Routing application

Entitlement Specific LSO/RSO Super Super- Import_


permissions Key visor Export

Open Application None

Activate Schema None - -

Add Keyword None -

Add Rule None -

Add Schema None -

27 March 2015 107


Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific LSO/RSO Super Super- Import_


permissions Key visor Export

Approve Schema None -

Def Rule None -

Mod Keyword None -

Mod Rule None -

Mod Schema None -

Mod Active Schema None - - -

Open Routing Point Routing Points - None prohibited None prohibited None prohibited

Rem Keyword None - -

Rem Rule None -

Rem Schema None - -

7.17 Security Definition Application


Description
The LSO/RSO or other entitled user can use the Security Definition application to define which
Alliance Access application functions each user can access, by assigning an operator profile to
each user.
The LSO/RSO or other entitled user can use the application to:

create, modify, or remove operator definitions, profiles, and units

generate full operator and operator profile details reports

configure various system-wide security parameters, such as the number of days after which a
user password has to be changed

approve units and operators (security officers usually approve operators)


Only the LSO/RSO can use Security Definition to modify the value of security parameters.

Entitlements and permissions within the Security Definition application

Entitlement Specific LSO/RSO Super Supervisor Import_ IPLA_


permissions Key Export Oper

Open Application None -

Add Operator None -

Add Profile None -

Add Unit None - -

Approve LDAP Approve Left or - - - -


Approve Right part

Approve Operator Approve Left or Left - - - -


Right part (Left/
Right)

Approve Unit - - - -

108 Security Guide


Default Operator Profiles

Entitlement Specific LSO/RSO Super Supervisor Import_ IPLA_


permissions Key Export Oper

Auth Server Config Left Secret (Yes/ Yes - - - -


No)
Right Secret (Yes/ Yes - - - -
No)

Configure LDAP None - - - -

Create Op List None - - - -

Disable Operator None - -

Display Auto None - - - -


Password(1)

Enable Operator None - -

Mod Component None - -

Mod Operator None -

Mod Profile None -

Mod Security None - - - -


Parameters(1)

Mod Unit None - -

Rem Operator None - -

Rem Profile None - -

Rem Unit None - - -

Reset User None - - - -


Password(1)

Reset Peer Officer None - - - -


Password(1)

(1) These entitlements cannot be re-assigned directly to other operators. However, if an operator is given the
entitlement to Approve Operators, this also allows the operator to display and print other operators' system
passwords and reset operators' user passwords. The Mod Security Parameters and Reset Peer Officer Password
entitlements are unique to the LSO/RSO and cannot be assigned to other operators. Also, the LSO/RSO can only
use the Reset Peer Officer Password entitlement if the Password: Reset Peer Officer Pwd security parameter has
previously been set to Yes.

7.18 SWIFT Interface Application


Description
This application enables an entitled user to log on through SWIFTNet to the SWIFT Financial
Messaging Service (FIN) to send and receive MT messages:

1. An entitled user first uses a logical terminal to log into APC (Application Control). APC is
the SWIFT application that controls communication sessions between a logical terminal and
SWIFT, and allows a user to send APC messages.

2. After successfully logging on, the user selects FIN, the SWIFT service through which all
SWIFT user-to-user MT messages are sent and received.

27 March 2015 109


Alliance Access 7.1 on Alliance Web Platform

To send messages over FIN, the user must have PKI secrets stored on Hardware Security
Modules (HSMs). The logical terminals will use these HSMs for authentication and will use the
Relationship Management Application for authorisation.
The user uses the SWIFT Interface application to:

define the characteristics of the connections to the SWIFTNet FIN service, and to monitor
and control sessions

schedule logging on and out to occur automatically at specified times

define which delivery queues in which SWIFT should store output messages in (known as
delivery subsets)

Entitlements and permissions within the SWIFT Interface application

Entitlement Specific permissions Super Super- Import Operator


Key visor Export

Open Application None

Add Action None -

Ena / Dis Auto Mode None -


(Enable/Disable )

Ena / Dis Re-Connect None - -


(Enable/Disable)

Login/Select... None -

Modify Action None -

Modify LT None -

Modify Subsets None -

Own Destination List List Own Destinations None None None None
(Allowed/Prohibited) prohibited prohibited prohibited prohibited

Redefine Delivery None - -

Remove Action None -

Enable LT None - -

Disable LT None - -

Remove LT None - -

7.19 SWIFT Support Application


Description
This application provides supporting functions to the SWIFT Interface application.
It allows an entitled user to:

install Message Syntax Tables (MSTs) for MT messages

install message standards for MX messages

import and export templates for MT, APC, and MX messages

define logical terminals (LTs)

110 Security Guide


Default Operator Profiles

assign LTs to MST entries

manage application service profiles

install and activate Value-Added Service (VAS) parameter files

provide extraction information for user-defined keywords


A message syntax table contains descriptions of all message types that can be sent and
received over FIN. Each logical terminal that a user's institution can use is identified by a
combination of the BIC-8 for the destination, plus a single-character terminal code. A user uses
the SWIFT Support application to define these details for each logical terminal, and to assign an
MST to the logical terminal.
Alliance Access validates each message by checking its syntax against the MST assigned to
the logical terminal. Alliance Access informs the user if there are any errors.
SWIFT provides an MT Standards release a few months before the new message syntax goes
live. This is useful for training purposes. For example, certain LTs can be assigned to the
current MST for live use, while other LTs (of a Test and Training destination) may be assigned
to the future MST for test and training use.
Message standards provide the information necessary to create and view MX messages.
Value-Added Services (VAS) are optional additional services which involve a central clearing
institution. A user can only use these services by arrangement with the central institution, and
after the user has installed a VAS parameter file using the SWIFT Support . These files are pre-
defined according to the various VAS registered with SWIFT.
It is possible to install several Value-Added Services with the same service name, provided their
service administrator destinations (CIDs) are different. An own destination cannot be subscribed
to more than one VAS with the same name.

Entitlements and permissions within the SWIFT Support application

Entitlement Specific permissions Super Super- Import_ Operator


Key visor Export

Open Application None

Activate VAS None - - -

Add Keyword None -

Add LT None -

Remove LT None - -

De-activate VAS None - - -

De-install VAS None - -

Export Msg Templates None - - -

Import Msg Templates None - - -

Install Msg Standard None - -

Install Syntax None - -


(Message Syntax
Table)

Install VAS None - -

Manage ASP None - -

Mod Keyword None -

27 March 2015 111


Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific permissions Super Super- Import_ Operator


Key visor Export

Modify LT None -

Modify VAS None - - -

Own Destination List Own Destinations None None None None


(Allowed/Prohibited) prohibited prohibited prohibited prohibited

Rem Keyword None - -

Remove Msg Standard None - -

Set Default Live None -

Set Default T&T None -

7.20 SWIFTNet Interface Application


Description
The SWIFTNet Interface application provides the functionality required to send and receive MX
messages (Standards MX messages) and FileAct messages between Alliance Access and the
selected SWIFTNet service. Message flow is controlled using emission profiles for outgoing
messages and reception profiles for incoming messages. Functions are provided to allow an
entitled user to define, enable, and activate emission and reception profiles for sending and
receiving MX and FileAct messages in real-time or store-and-forward mode. For each profile
defined, a SWIFTNet connection is assigned and a SWIFTNet service designated. Through the
SWIFTNet Interface Application, profiles are enabled and activated ready for use. Schedules
can be set up for automatic activation and deactivation. A user also uses the SWIFTNet
Interface application to set up input channels for store-and-forward messaging, which provide
first-in, first-out delivery from sender to receiver, gap detection, and duplicate detection.

Entitlements and permissions within the SWIFTNet Interface application

Entitlement Specific permissions Super Supervisor Import_ Operator


Key Export

Open Application None

Activate EProf None -

Activate RProf None -

Add EProf None -

Add RProf None -

Adopt IChan None -

Adopt OChan None -

Create IChan None - -

Create OChan None - -

Deactivate EProf None -

Deactivate RProf None -

Delete IChan None - -

Delete OChan None - -

112 Security Guide


Default Operator Profiles

Entitlement Specific permissions Super Supervisor Import_ Operator


Key Export

Disable EProf None -

Disable EProf Auto None - -

Disable RProf None - -

Disable RProf Auto None - - -

Enable EProf None - -

Enable EProf Auto None - -

Enable RProf None - -

Enable RProf Auto None - -

Modify EProf None -

Modify RProf None -

Open/Print EProf Services None None None None


(Allowed/Prohibited) prohibited prohibited prohibited prohibited

Own Destinations None None None None


(Allowed/Prohibited) prohibited prohibited prohibited prohibited

Open/Print IChan Own Destinations None None None None


(Allowed/Prohibited) prohibited prohibited prohibited prohibited

Open/Print OChan Own Destinations None None None None


(Allowed/Prohibited) prohibited prohibited prohibited prohibited

Open/Print RProf RT None

Open/Print RProf SnF Own Destinations None None None None


(Allowed/Prohibited) prohibited prohibited prohibited prohibited

Remove EProf None - -

Remove IChan None - -

Remove OChan None - -

Remove RProf None - -

RT File Get Request Service(s) None None - -


(Allowed/Prohibited) prohibited prohibited
Request type(s) None
prohibited
(Allowed/Prohibited)

Own Destination (1) None None - -


(Allowed/Prohibited) prohibited prohibited

Authoriser DN(2) None None - -


(Allowed/Prohibited) prohibited prohibited

Schedule EProf Add Action (Yes/No) Yes No Yes -


Modify Action (Yes/No) Yes No Yes -

Remove Action (Yes/ Yes No Yes -


No)

Schedule RProf Add Action (Yes/No) Yes No Yes -

27 March 2015 113


Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific permissions Super Supervisor Import_ Operator


Key Export

Modify Action (Yes/No) Yes No Yes -

Remove Action (Yes/ Yes No Yes -


No)

(1) You can use the underscore (_) wild card in any position in a BIC and it can be present multiple times in the same
BIC. The percent (%) wild card character is not permitted.

(2) You can use the underscore (_) wild card for one character and/or the percent (%) wild card for any number of
characters.

7.21 SWIFTNet Support Application


Description
This application is used to manage the SWIFTNet environment. The SWIFTNet Support
application provides functions for defining SWIFTNet connections.
These functions are as follows:

add a SWIFTNet connection: to create a SWIFTNet connection

modify a SWIFTNet connection: to change the settings of a SWIFTNet connection

mark a SWIFTNet connection as Reliable: to change the status of a SWIFTNet connection


from Not Reliable to Reliable

remove a SWIFTNet connection: to delete a SWIFTNet connection

Entitlements and permissions within the SWIFTNet Support application

Entitlement Specific permissions LSO RSO Super Super- Import_


Key visor Export

SNL Handling Connection Handling Yes Yes Yes Yes Yes


(Yes/No)

First Part Local Yes No Yes Yes No


Authentication Key
(Yes/No)

Second Part Local No Yes Yes Yes No


Authentication Key
(Yes/No)

Reset Connection Yes Yes Yes Yes No


Status (Yes/No)

7.22 System Management Application


Description
This application is used to configure and control Alliance Access.
It allows the LSO/RSO or an entitled user to:

define printers (on UNIX or Linux servers only)

114 Security Guide


Default Operator Profiles

modify the values for a large range of system parameters, such as time and date formats,
frequency of disk space checks, and so on

shut down the system (for example, for file maintenance)

restart the system, either in housekeeping mode, when only a single user can be signed on
(for example, to define logical terminals), or in operational mode (the normal, multi-user
mode)

hold or release message queues

back up or restore Alliance Access data or archives

increase database resiliency by making use of the database recovery functionality

stop or start a component

define events that must be set as alarms, and set the distribution lists for these alarms

Entitlements and permissions within the System Management application

Entitlement Specific LSO/RSO Super Supervisor Import_ IPLA_


permissions Key Export Oper

Open Application None -

Add Device None - -

Add Dist. List None -

Add Queue None - -

Backup (Software, Store schedule No Yes Yes - -


Data, and Archives) (Yes/No)

Modify operating No Yes Yes - -


mode (Yes/No)

Hold Queue None -

Manage Rec None - -


Backup(1)

Mod Config. Param. Manage Encrypted Yes Yes Yes Yes Yes
(2) Parameters (Yes/
No)

Mod Device None - -

Mod Dist. List None - -


(Distribution list)

Mod Event Dist. None -


(Distribution)

Mod Queue None

Release Queue None - -

Rem Device None - -

Rem Dist. List None - -


(distribution list)

Rem Queue None - - -

Reset Event None - -


Distribution

27 March 2015 115


Alliance Access 7.1 on Alliance Web Platform

Entitlement Specific LSO/RSO Super Supervisor Import_ IPLA_


permissions Key Export Oper

Restart Store schedule No Yes Yes - -


SWIFTAlliance
Modify operating No Yes Yes - -
mode (Yes/No)

Restore (Data, and None - - -


Archives)

Stop SWIFTAlliance Store schedule No Yes Yes - -


(Yes/No)

Modify operating No Yes Yes - -


mode (Yes/No)

Stop/Start None - -
Component

(1) Only effective if option 14:DATABASE RECOVERY is licensed.

(2) An operator with this entitlement can update values for Integration Platform component-specific configuration
parameters using the Alliance Access Configuration GUI.

116 Security Guide


Securing System Resources

8 Securing System Resources


Overview
This section describes various methods provided by Alliance Access to help secure your system
resources.

8.1 Backup Strategies


Introduction
This section explains the common backup utilities provided by Alliance Access and the
operating system, and helps you avoid the most frequent mistakes.
The most frequent mistakes are due to:

incorrect understanding of terminology used

incorrect understanding of the functionality

insufficient disk space requirements

faulty automatic procedures and backup scheduling


Possible problems which occur as a result are:

database corruption

software corruption

hardware failure

manual deletion of files

8.1.1 Contingency Systems


Overview
The following contingency systems can increase your system availability when there are
problems or system failure.
Each institution is responsible for selecting the one that meets their requirements.

8.1.2 Backup and Restore Facilities


Overview
A daily backup of all operational data is highly recommended. This helps to ensure the
continuing availability of Alliance Access configuration and operational data, if a system failure
occurs.
The Alliance Access Administrator can take a backup of the database. For more information,
see the Administration Guide for AIX, Linux, Oracle Solaris, or Windows.
Alliance Access provides a Backup and Restore facility which can be used while Alliance
Access is running. In addition, Message Archive and Event Log archives can be backed up and
later restored, if required.

27 March 2015 117


Alliance Access 7.1 on Alliance Web Platform

If the Calendar entity has been used to create a calendar, then Alliance Access data and
archives can be scheduled to be backed up automatically at specific times on specific days - for
example, at 8:00 pm every working day.

Data backup
Each manual backup operation enables a Supervisor or privileged operator to back up one of
the following:

Journal Archive: the existing Event Log archives, as managed within the Event Log entity.

Message Archive: the existing Message archives, as managed within the Message File entity

Alliance (Saved) Data (except Journal and Message): this includes all operator and operator
profile definitions, security parameters, password files, Relationship Management Application
authorisations, system management parameters, and so on (but excluding all messages and
events not yet archived).

Note With an automated backup all the archives that are in the database are scanned
for backup. With a manual backup, the operator can select the archives to be
backed up.

When backing up archives automatically, the operator can select a backup directory and one of
the following options:

Backup: the archives remain on the local disk after the backup operation has been
completed. When an archive is backed up, it cannot be backed up again.

Backup and Remove: the archives are deleted from the local disk after the backup has been
completed. When an archive is backed up, it cannot be backed up again. An archive not
backed up cannot be deleted.

Remove: the archives are deleted from the local disk and not backed up (with a manual
deletion, a warning is given if the archives have not been backed up yet). An archive not
backed up cannot be deleted.

Note If a calendar has been created, then an Alliance Workstation user can schedule the
automatic backup of the Alliance data or archives at the server. The backup itself
must take place at the server.

Entitlements to the Alliance functions to back up data and archives, and to restore archives are
normally provided to security officers, the system administrator, and supervisors. However,
these entitlements can also be assigned to specific operators, if required.

Restoring archives
The Alliance configuration package on the Web Platform provides facilities to restore Message
Archive and Event Log archives from backup files.
During the restore operation, existing archives may be overwritten.

Restoring Alliance data


The Alliance System Administrator can restore Alliance data using the facilities of the System
Administration application (on Windows only) or command line tools. For more information, see
the Administration Guide for AIX, Linux, Oracle Solaris, or Windows.

118 Security Guide


Securing System Resources

8.2 Software and Data Integrity


Introduction
Software and data integrity is achieved in Alliance by ensuring that:

only authentic Alliance software is installed

software is not altered after installation

data is not altered after it has been stored

only genuine Alliance processes and operators

have access to Alliance resources

are able to modify data files

have access to secret information


This section describes the many protections built into Alliance which ensure that software and
data files remain secure and cannot be fraudulently altered, deleted, or tampered with.
On UNIX or Linux, Alliance software and data integrity relies on the underlying security of the
UNIX or Linux operating system and the UNIX or Linux file system. It is therefore most important
that the UNIX or Linux operating environment is properly configured and managed - as
discussed in "Security on AIX, Linux, or Solaris Systems" on page 21.

8.2.1 Data Backup


Description
While all possible steps are taken to provide the best possible security, there can be no such
thing as absolute security. Users are therefore encouraged to take regular software and data
backups. Having a recent copy of your software available to restore, offers a means of
recovering corrupted or lost data. Additional operational security is achieved by the use of Dual
Configuration options. For more information about these options, see "Minimising the Impact of
System Failure" on page 126.
Regular backups are the best way to protect against the consequences of innocent and
fraudulent file and data corruption or deletion. Based upon your traffic volumes, configurations,
and preferences, it is recommended that you regularly:

archive messages and events

back up archives

back up the Alliance database

back up the Alliance software following installation, re-installation, or software update

back up the operating system following Alliance installation

27 March 2015 119


Alliance Access 7.1 on Alliance Web Platform

8.3 Software Integrity


Introduction
The integrity of Alliance software is checked at various times to ensure that only genuine
Alliance software - approved by SWIFT - is used. The integrity of executable files is checked:

at installation time (all files)

whenever any Alliance process is started (specific files)

at server startup, if the security parameter, Software Check At Startup, is set to Yes

at the request of the Alliance System Administrator (all files)

8.3.1 Software Authentication - At Installation


Description
Whenever the Alliance software is installed the Initialisation and Master Passwords are
recalculated and checked against the information entered during installation. Both passwords
are then combined with random data to produce the Master Encryption Key, as described
earlier.
All Alliance software is authenticated by SWIFT. Two different mechanisms are used to identify
genuine Alliance executable files:

full Cyclic Redundancy Check (CRC) is calculated across all bytes of each executable file
and compared with trusted reference values (see further for details). This process is used at
installation, and may be repeated at other times, by user request.

at run time, a simplified CRC check is calculated (across a limited number of bytes in each
file) and compared with trusted reference values (see further for details). This process is fast
enough to enable Alliance to verify the check value for an executable file every time that the
file is run.
On Windows:
When SWIFT builds a new release of the Alliance software, the full, and simplified CRC values
of each executable in the release are calculated. Each pair of CRCs is then encrypted and
written to a reserved location within the respective executable.
When Alliance is installed, the data integrity check (see "Data Integrity Checking" on page 122)
recalculates the CRCs of all executables and compares the calculated values with the trusted
reference values that it extracts (and decrypts) from the executables.
When any executable is started, its simplified CRC is recalculated and compared with the
extracted and decrypted reference value (see "Software Authentication - At Run Time" on page
121 for details).
On UNIX or Linux:
The Alliance release media contains a list, determined by SWIFT, of the CRC values applicable
to each executable file on the release media (both full CRC values and simplified values).
During installation, these values are read from the media. Both CRC check values (1 and 2
above) are calculated for each executable file loaded from the media, and compared with the
trusted values provided by SWIFT. Any discrepancies are reported, and the installation process
aborted.

120 Security Guide


Securing System Resources

The trusted CRC check values are stored in the Alliance database, and thereafter protected by
the record-level data integrity checks described in "Data Integrity Checking" on page 122.
This mechanism ensures that only genuine Alliance software is loaded during the installation
process. Additional checks are made (see "Data Integrity Checking" on page 122) to ensure
that software has not been tampered with after installation.
In addition, the release media contains a list of the correct UNIX or Linux file permissions for all
software and data files used in Alliance. These values are also read during the installation
process and stored in the Alliance database. All UNIX or Linux file permissions, for all installed
software and data files, are checked following installation. The trusted list of permissions is used
as a reference for later checks.
A separate Data Integrity Check ensures that the CRC values and file permissions, once stored
in the Alliance database, cannot be subsequently altered without detection.

8.3.2 Software Authentication - At Run Time


Description
Each Alliance application consists of a number of processes. Alliance is built on the principles of
client and server processes, whereby:

a client process is one which requests services from other processes

a server process is one which provides services to clients

clients request services from servers through a mechanism known as Remote Procedure
Calls (RPCs)
Within Alliance, two executive processes manage all client-server communications and
implement a number of different security mechanisms to ensure the integrity and security of all
inter-process communication:

the executives monitor each other's existence and ensure that no other executive processes
exist

whenever a request is made to launch an Alliance process (that is, to run an executable file)
a simplified CRC check is performed on that file, and the calculated value compared with the
trusted value (see "Software Authentication - At Installation" on page 120). If a difference is
found, then that process is not started, and a severe signature error event is recorded in the
Event Log. This ensures that inter-process communication only takes place between genuine
Alliance programs.

all processes are registered in a database. Processes not included in this database cannot
communicate with Alliance processes.

a security block is used in all RPC communications which enables file ownership and
permissions, operator identities, process IDs and such like to be verified. The full format of
this security block is not published outside of SWIFT, and the code used to create or verify
the security block is highly complex.
Collectively, these mechanisms ensure that only genuine Alliance software is used at run time
and make it extremely difficult for rogue processes to access Alliance resources and data files.
The security mechanisms implemented for inter-process communications provide the basic
framework for ensuring the integrity of processes running on distributed systems.

27 March 2015 121


Alliance Access 7.1 on Alliance Web Platform

8.4 Data Integrity Checking


Introduction
Alliance maintains database files, each of which consists of a number of records. Each record
stores a particular piece of information. The integrity of this data is checked at various times to
ensure that no information has been corrupted or altered since being stored in the database. A
record-by-record "data integrity check" is performed on all data stored in an Alliance database,
whenever data is:

read from a database

modified in a database
A new check value is calculated whenever a record is updated or a new record is added to a
database.
Data integrity checks are performed in two different ways, depending on the type of data:

for all Alliance data files (operational data, configuration data, password files, operator and
profile definitions, and so on) the check consists of calculating a CRC checksum on all bytes
of a record. The resulting value is then diversified, using the Alliance Master Encryption Key,
to create a check value that is impossible to recreate without knowledge of the Master
Encryption Key unique to that Alliance installation. The check value is added to the end of the
record and stored in the database, alongside the data it is used to protect. This same
procedure is also used to protect data in the Message File and in the Event Log.

for archives, the check consists of calculating the CRC checksum and adding it to the end of
the record, without the diversification of the Master Encryption Key.
Data integrity checking ensures that any changes to stored data are detected at the next read or
update of that record. It does not, however, protect against the deletion (accidental or
otherwise) of data records.
Checking also ensures that data backups contain information that is unique to the Alliance
installation they were taken from and can, therefore, only be restored to the same installation. If
someone attempts to restore data to another installation of Alliance, then the data integrity
check fails even though the data is valid, because the Master Encryption Key is different for
each installation of Alliance. For example, this prevents operator definitions from one installation
being loaded into another installation.
The backups of archives, because they do not contain checks specific to an installation, can be
restored to an installation other than the one they were backed up from. This allows, for
example, Message File archives to be restored to a system that has been completely reinstalled
and so uses a different Master Encryption Key.

8.4.1 Sequence Numbering


Description
The data integrity checking described earlier does not protect against the deletion of records
within a file. The implementation of file-level CRC checks is time consuming to calculate -
particularly on large files such as the Message File and the Event Log where the content is
constantly changing.
Within the Message File, all SWIFT messages already have an input or output sequence
number, per session, enabling deleted (or lost) messages to be identified.
Events in the Event Log are also sequence numbered. Fraudulent operators cannot, therefore,
hide their activities by deleting events from the Event Log, without being discovered. Security

122 Security Guide


Securing System Resources

officers must make regular checks to ensure that all events are present in the Event Log - there
must be no gaps in the sequence numbering of entries.

8.4.2 Bank Query


Description
In emergencies, the System Administrator (or some other appropriate user) can run the
saa_bankquery command line tool to repair or modify corrupted or damaged data.
This tool provides powerful facilities for checking the integrity of Alliance data and for repairing
corrupted Alliance databases.
The tool, which the Alliance System Administrator normally uses under the guidance of Support,
is described in "Offline Maintenance Utilities" on page 35, and in detail in the Administration
Guide for AIX, Linux, Oracle Solaris, or Windows.

8.5 Encryption of Secret Data


Introduction
Sensitive and secret data stored within Alliance is encrypted before storage to provide read
protection against unauthorised access. Data is encrypted during add and update operations,
and decrypted during read operation.
At the database layer, an algorithm is used, with the Alliance Master Encryption Key, to encrypt
specific data fields - in a way which ensures that decryption is only possible on the Alliance
installation which owns that Master Encryption Key.
In addition, encrypted data is protected at the record level against unauthorised alteration, as
with all other data stored in Alliance database, by the Data Integrity Checks described
previously.
On UNIX or Linux only:
Database encryption is performed by servers, not clients. In a distributed system, this would
mean that data is only protected once it reaches the relevant server and would not, therefore,
be encrypted over inter-connecting LANs.
All system management scripts provided with Alliance are encrypted and cannot be read by
System Administrators who have access to the UNIX or Linux shell.

8.5.1 Encryption of Specific Data Fields


Introduction
The following data items are automatically encrypted in the Alliance database.

Local authentication keys


Local Authentication Keys (LAUs) are used to protect the transmission of messages between
Alliance and external message partners. These keys (consisting of a Send and Receive key, per
message partner) are entered within the Application Interface and stored in the Alliance
database in an encrypted form, using the local Master Encryption Key.
With SWIFTNet Public Key Infrastructure for FIN, message signing is done by a dedicated HSM
on the SWIFTNet Link host. The path between Alliance and the SWIFTNet Link host must be
secured, and Local Authentication can be used for this.

27 March 2015 123


Alliance Access 7.1 on Alliance Web Platform

Private and public keys (SWIFTNet Public Key Infrastructure)


Private and public keys are used to authenticate FIN messages. A PKI-based digital signature is
calculated (signed) by SWIFTNet Link using the sender's private key. When the message is
received, the signature is verified for authenticity by the receiver's SWIFTNet Link against the
public key of the sender. The sender's public key is retrieved from the central SWIFTNet
Directory and can be used by all correspondents to verify PKI signatures generated from a
sender's private key.
The integrity of the message is also verified by comparing the digest of the message that was
signed against a digest calculated by Alliance when the message is received.

8.5.2 Password Encryption


Introduction
All passwords used in Alliance are stored in an encrypted form. Following the entry of an
operator password, the password entered is encrypted and compared with the (encrypted) value
stored in the Alliance database. In this way, the operator passwords themselves do not have to
be stored unencrypted in Alliance.

Operator passwords
All operator passwords used in Alliance are stored in an encrypted form using a SWIFT
proprietary algorithm with the local Master Encryption Key. As password values do not have to
be decrypted, the use of a one-way encryption algorithm ensures that actual passwords cannot
be deduced even if the encrypted value is known.

Master password
The two parts of the Alliance Master Password are used as the operator passwords for the left
security officer and the right security officer. As such, they are treated like any other Alliance
operator password and are encrypted using a SWIFT proprietary algorithm with the local Master
Encryption Key.

Initialisation password
The Initialisation Password is used to verify licensing details during the installation process.
Thereafter it is stored in a secret location and used, with other data, in the calculation of the
Master Encryption Key.

8.5.3 Alliance Server and Alliance Workstation Connection


Security
RPC authentication
Each Alliance executable has an associated code signature that is stored in the Alliance
database. When an executable starts a process running, the code signature for the executable
is calculated and checked against the code signature stored in the database. If the values
match, then the Alliance process is said to be authenticated.
Security officers (left security officer and right security officer) can use the System: RPC
Authentication parameter to set the level of security that applies for client processes making
Remote Procedure Calls (RPC) to server processes.

124 Security Guide


Securing System Resources

The different levels of security are:

Off. Processes making RPCs are not checked to ensure that they are authenticated.

Process Authentication. Processes making RPCs are checked to ensure that they are
authenticated. This is the default value.

Data Integrity/Confidentiality. In addition to Process Authentication, Alliance calculates a


check value based on the data in the RPC call. The RPC call data is encrypted using the
encryption algorithm to ensure confidentiality. The check value and the RPC call are then
passed to the server. The server recalculates the check value from the RPC data, and
compares it to the check value that it received. This ensures the integrity of the RPC data. If
any changes have been made to the data, then the check values will not match.
Security officers (left security officer and right security officer) use the Security Definition entity
to set the value of the System: RPC Authentication parameter. For more information, see
modifying security parameters in the Configuration Guide.

Server authentication and SSL


If Data Integrity or Data Confidentiality is selected for the RPC Authentication parameter then
the Alliance servers are initialised with SSL (Secure Socket Layer) enabled, which means that
Server Authentication must be set up for the communication between Alliance Workstation and
the Alliance Server.
When Server Authentication is used, the System Administrator must set up a DN and obtain a
certificate. Either a self-signed certificate, or a Certification Authority Certificate request can be
generated by the System Administrator. The Certification Authority Certificate request must then
be submitted to a Certificate Authority to obtain the certificate. Tools are provided to generate
the self-signed certificate or CA Certificate request and to import the resulting certificate into
Alliance.
For further details of Server Authentication certificate tools, see RPC and SSL security in the
Installation Guide for AIX, Linux, Oracle Solaris, or Windows.
To set up the Alliance Workstations for Server Authentication, the System Administrator must
first distribute the file containing the certificate. Then for each Alliance Workstation, Server
Authentication can be selected in the Instance Configuration details of the Alliance Control
application and the DN and location of the certificate entered.
For further information, see the Installation Guide for AIX, Linux, Oracle Solaris, or Windows.

Note To avoid SSLv3 (CVE-2014-3566 - POODLE) vulnerability, SWIFT recommends


that you disable SSL encryption in your browser settings to access SWIFT
products and services. By doing so, you will eliminate any residual risk that this
SSLv3 vulnerability may cause.
Before disabling SSLv3, SWIFT recommends that you test the compatibility of TLS
with all of your various Browse services. For information on configuring the browser
to use TLS, see Web browser settings in the Alliance Web Platform Installation
Guide for AIX, Linux, Oracle Solaris, or Windows. If you encounter difficulties
reaching a Browse service, consult with the relevant service provider.
SWIFT will cease to accept SSLv3 encryption for browser connections in early
2015.

27 March 2015 125


Alliance Access 7.1 on Alliance Web Platform

8.5.4 The Alliance Master Encryption Key


Description
Alliance uses a number of different encryption mechanisms to protect sensitive and secret data.
A Master Encryption Key is used to ensure that no one else can perform the same encryption or
decryption of data as Alliance. The key is unique for each installation of Alliance in an institution
and is derived, at installation time, from a combination of:

the Initialisation Password

the Master Password

random data generated during the installation process


The precise calculation of this key and the nature of its encrypted storage within Alliance are
secret.
The key:

diversifies checksums and Cyclic Redundancy Check (CRC) values, to create a "signature"
that is unique to each installation of Alliance. For details, see "Data Integrity Checking" on
page 122.

acts as a local encryption key (for use with different algorithms) to encipher secret data in a
way that is unique to each installation
Use of the Master Encryption Key prevents individual files (such as operator definitions or
passwords) from being moved from one Alliance installation to another.

8.6 Minimising the Impact of System Failure


Introduction
This section describes ways of minimising the impact of system failure.
Two possible types of failure are discussed:

software, for example a processing failure

hardware failure, for example of a disk drive


The ideal configuration of any Alliance Access installation depends very much upon individual
requirements. SWIFT personnel are always available to discuss the security advantages of
different system configurations and offer advice.

8.6.1 Software Failure


Introduction
Occasionally, an Alliance process may fail or terminate for a variety of reasons: RPC time-outs,
system management actions, "kill" command issued from UNIX or Linux or due to software
errors.
Any unexpected failure of Alliance processes is recorded in the Event Log and an automatic
recovery procedure instigated within Alliance.
If a server process crashes while handling the requests of one or more clients, then these client
processes receive an error. If the clients were performing an update operation, then they
typically quit. If they were performing a read, then they continue to run. In any case, the server

126 Security Guide


Securing System Resources

restarts automatically, and all existing and still-running client processes transparently re-connect
to the new server.
For details about all the actions necessary for dealing with system failures and for repairing
corrupted files, see the Administration Guide for AIX, Linux, Oracle Solaris, or Windows.

8.6.1.1 Monitoring of System Resources

Overview
Within Alliance Access, user-definable parameters may be set, related to the availability of
system resources.
Other controls, managed within Alliance Access, abort operations such as printing and archiving
if insufficient disk space is available.
For more information about configuration parameters for controlling disk space, see the
Configuration Guide.

8.6.2 Hardware Failure


Description
Although the reliability of hardware has increased in recent years, hard disk drives are still
considered to be one of the most vulnerable items of system hardware.
Because of the critical nature of their use (that is, to store operating system software,
application system software, system configuration files, and data files) the loss of a hard disk
can easily render a system inoperable. Apart from the physical failure of the disk itself, the files
stored on the disk may either be corrupted (but recoverable) or damaged to such an extent that
all software and data files are lost.
Although Alliance uses automatic recovery procedures if data is found to be corrupted, to
minimise the operational impact of hard disk failure, it is recommended that regular software
and data backups are taken.
Licence option 14:DATABASE RECOVERY allows you to create database recovery backups of
the Alliance Access database. In the case of data file loss or disk failure, the recovery backups
can be restored locally or remotely and allow a fast restart of operations. For more information,
see database recovery in the Administration Guide for AIX, Linux, Oracle Solaris, or Windows.
The following procedures may be adopted on servers to ensure that Alliance software and
reliable operational data may be recovered following a disk failure:

use of dual disks

use of dual hardware configurations

8.6.2.1 Backup and Archive Procedures

Overview
The most reliable means to protect operational data is to take regular backups of all software,
Alliance data, Message Archive, and Event Log archives.

27 March 2015 127


Alliance Access 7.1 on Alliance Web Platform

Message File entity


The Message File entity provides facilities for the archiving of messages processed within
Alliance. Only completed messages may be archived (that is, where all instances of that
message have been completed at the time of the archive). Operators may force the completion
of a message, if required. If a live message is discovered with a creation date in the date range
of the archive, then the archiving process does not start for that date. The messages remain in
the Message File and are not archived.
The Event Log entity provides facilities for archiving entries. Only events recorded up to the end
of the previous day may be archived.
If a calendar has been created, then the Message File and Event Log can be scheduled to be
archived automatically on specified days.
When first created, archives remain part of the database.

System Management entity


The System Management entity provides dedicated facilities which enable the following data to
be backed up (and for archives to be later restored):

Journal Archive. One or more Event Log archives may be backed up. Events generated on
the current day do not appear in the archive - they remain in the Event Log.

Message Archive. One or more Message archives may be backed up. Messages which have
not been completed (that is, fully processed) are not archived - they remain in the Message
File.

Alliance (Saved) Data (except Journal and Messages). All Alliance configuration data
(security definition and system management parameters, operator definitions, password files,
and so on) as currently saved in the database, may be backed up and later restored (by the
Alliance System Administrator) for use with the same Alliance installation. However, the
Message File and the Event Log are not backed up.
If the licence option 14:DATABASE RECOVERY is present, then the System Management
entity provides a facility to enhance the resilience of the Alliance Access database. In case of
disk failure or data file loss, the necessary recovery information is available for a restore of
the Alliance Access database to its last committed state. For more information, see database
recovery in the Administration Guide for AIX, Linux, Oracle Solaris, or Windows.
If a calendar has been created, then the Alliance data can be scheduled to be backed up
automatically.

Note If a calendar has been created, then an Alliance Workstation user can schedule the
automatic backup of the Alliance data or archives at the server. The backup itself
must take place at the server.

If data backups are taken using the System Management entity, then Alliance is running at the
same time. As a daily procedure, therefore, supervising operators must:

archive any completed messages and events not yet archived

take backups of the various archives

store the backups in a secure place

Note Messages which were not completed at the time of the last shutdown, and events
generated on the current day, are not included in these backups.

128 Security Guide


Securing System Resources

8.6.2.2 Integrity of Alliance Software and Data

Overview
Following a system failure, remember that:

License information is stored in the database and is part of any database backup. If Alliance
is completely re-installed (and therefore, re-licensed) and an existing backup of the database
is restored, then the new licensing information is overwritten by the licensing information
stored in the backup.

Existing backups of the database may not be used with a new installation (hence the need to
take a complete backup of the installed Alliance software following installation).

Backups of archives may be used by any installation of Alliance.


"Software and Data Integrity" on page 119 describes the many facilities inherent within Alliance
which ensure the integrity of the software and data used by Alliance.

8.6.3 Power Failure


Overview
Following a power failure, the operating system takes automatic action to verify the resources
under its control.
If the file system on disk is found to be in order, then Alliance may be restarted. Following the
restart, Alliance detects that the processes running at the time of the power loss were not
completed and an automatic process recovery takes place.
If the power loss damages the disks (resulting in the irrecoverable loss of data), then the same
procedures as for the failure of a single disk (for example, adaptor failure) apply.
For details of recovery procedures, see database recovery in the Administration Guide for AIX,
Linux, Oracle Solaris, or Windows.

27 March 2015 129


Alliance Access 7.1 on Alliance Web Platform

9 Controlling Message Processing


Introduction
This section describes the Alliance functions that are used to control message processing.
Message processing can be performed for MT messages (SWIFT format) using the SWIFT
Interface, for MX messages (Standards XML format) using the SWIFTNet Interface, for CREST
using the CRnet Interface (if your organisation uses CRnet), and for the Application Interface,
as follows:

MT messages are sent from Alliance to the FIN application (as SWIFT input messages) or
received in Alliance from the FIN application (as SWIFT output messages) - through the
SWIFT Interface application.

MX messages are sent from Alliance to the SWIFTNet network (as input messages) or
received in Alliance from the SWIFTNet network (as output messages) - through the
SWIFTNet Interface application.

For MT messages (SWIFT FIN user-to-user and FIN/APC system messages), the message
preparation applications are available to create, verify, authorise, and modify messages.

within Alliance, messages can be processed by various internal processing functions, by the
routing software, or as a result of operator action within other applications such as the
Message File application.

for CREST, messages may be input from customer applications to the Host service, or output
from the Host service to customer applications - through the CRnet Interface.

messages may be input from one or more local message partners (for example, from a
Mainframe) or output to one or more message partners (for example, to a Mainframe, or a
printer) - all through the Application Interface.

Applications
In addition, the system administrator, security officers and supervisors monitor the system and
control operator access by using the following applications:

Event Journal

Monitoring

System Management

Security Definition

Messages
Alliance stores all messages in an internal format. However, the text of a message is always
stored in the format of the external network from which it was received, or to which it is destined.
Alliance messages consist of the following four components:

Header: which records general information related to the message. There is always one
generic header per message

Message Text: which contains the data to be transmitted to the receiver by the sender (for
SWIFT messages, this includes all SWIFT header information, plus the text of the message).
There is always one message text per Alliance message.

130 Security Guide


Controlling Message Processing

User Interventions: each of which records user-level information about the processing,
or routing, of that message. There may be zero, one or several user interventions per
message.

Transmission Interventions: each of which records information, in a structured form,


related to the reception, and emission of that message into, or out of, Alliance. There may be
zero, one or several transmission interventions per message.

Message header
The Alliance header, which is separate from the actual message header, contains, among other
things:

a Unique Message Identifier or "UMID"

the date and time of message creation

sender and receiver addresses

transmission instructions

other reference information, some of which may be extracted from the message text (for
example, the transaction reference number)

Interventions
User interventions are typically added to a message by the routing process to confirm that a
particular action was performed on that message - for example, that the message was extracted
from a particular message queue, processed, and routed to another message queue as a result
of that processing. User interventions may be added by the system or by an operator.
Transmission interventions are automatically added to a message when that message enters or
leaves the Alliance environment. Each transmission attempt therefore results in a transmission
intervention being added to the message.
A message may be an original, a copy or a notification:

copies of messages may be created by routing functions and are typically sent back to the
message originator

notifications may also be created by routing functions and provide information about the
delivery status of messages (Originals and Copies). A typical notification may confirm that the
message was ACKed by the SWIFT.
Each original, copy, or notification represents a different "instance" of that same message. Each
instance of a message is processed independently by Alliance. An Alliance message itself is not
considered as completed until all instances of that message have been completed. Operators
with the appropriate entitlement, can force the completion of a message instance.

Message file
The Message File contains all instances of all messages. Messages may only be archived when
the original and all copies and notifications have been completed (or forced to be completed by
an operator).
A message is considered as created in Alliance either:

when it has been created using the Message Creation application (MT messages only)

when it has been created automatically by an Alliance application

27 March 2015 131


Alliance Access 7.1 on Alliance Web Platform

when a (pre-prepared) message has been successfully received, through the CRnet
Interface, from the Customer Host, or workstations using the CREST GUI

when a (pre-prepared) message has been successfully received, through the Application
Interface, from an external message partner.

when it has been received from an external network such as SWIFTNet.


Note that Alliance performs a conversion on MX messages to create an internal representation
of the message for Alliance's internal message format. Validation is also performed on MX
messages (containing well-formed XML or with a syntactically valid schema name only).
For more information, see the message information for SWIFT MX messages in the Daily
Operations Guide.

9.1 Message Preparation Controls


Overview
A number of facilities exist, which provide a flexible means of control over the message
processing functions of Alliance. These controls enable the principles of "need to know" and
"least privilege" to be implemented according to local requirements and to the duties, and
responsibilities of individual operators.
These controls are implemented, across a number of different applications, according to the
entitlements and the permissions defined in each operator's profile, as described in the following
sections.
The various functions required for the creation and subsequent processing of new messages
are provided within the following Alliance applications:

Message Creation application

Message Approval application

Message Modification application

Note These sections are only relevant for MT messages.


The sections are not relevant for MX messages or CRnet messages. To create,
modify, or approve MX messages, you must use Message Management, available
on Alliance Web Platform.

9.1.1 Message Creation


Overview
The Message Creation application enables an operator with the necessary entitlements to enter
original message texts. Assuming the correct entitlements and permissions, an operator can
create FIN user MT messages, FIN system messages and APC system messages.

Entitlements
Operator profiles are used to control the use of all message creation functions. Entitlements
may be granted or denied in relation to:

accessing the Message Creation application

creating new messages

132 Security Guide


Controlling Message Processing

completing messages

disposing messages by bypassing message approval

adding, modifying, and removing templates

overriding test requirements

the ability to route messages.


Some entitlements include permissions to enable operator access to functions to be further
restricted. The entitlement to create new messages has associated permissions indicating:

the message destinations that are allowed

the message types that are allowed (separate permissions are provided for FIN user MT
message types, FIN system message types, and APC system message types)

whether MT 999 messages (that is, text-only messages) can be broadcast to multiple
correspondents

the currency codes and amounts that are allowed

whether multiple retrieval of system messages is allowed

whether the use of the FINCopy service is allowed.


The entitlement to dispose message approval has associated permissions indicating:

the currency codes and amounts for which verification may be bypassed

the currency codes and amounts for which authorisation may be bypassed

the FIN user message types for which verification may be bypassed

the FIN user message types for which authorisation may be bypassed

the FIN system message types for which authorisation may be bypassed

the APC system message types for which authorisation may be bypassed.

9.1.2 Message Modification


Overview
Alliance routes inbound or outbound messages which it cannot process automatically to
message modification queues, so that operators can edit the messages to correct any errors.
An operator with the necessary entitlements can use the Message Modification application to
edit messages in the following message modification queues:

Text Modification

Emission Security Modification

Transmission Modification

Modification After Reception

Reception Security Modification

27 March 2015 133


Alliance Access 7.1 on Alliance Web Platform

Entitlements
Operator profiles are used to control the use of all message modification functions. Entitlements
may be granted or denied in relation to:

accessing the Message Modification application

the ability to modify messages in the different modification queues

"completing" (discarding) messages in the Text Modification queue

disposing message by bypassing message approval

bypassing authentication for one or more messages in the Reception Security Modification
queue

overriding test requirements

the ability to route messages.


Messages input through the Application Interface can also be sent to the Text Modification
queue, for modification within Alliance.
The entitlement to bypass message approval has associated permissions indicating:

the currency codes and amounts for which verification may be bypassed

the currency codes and amounts for which authorisation may be bypassed

the FIN user message types for which verification may be bypassed

the FIN user message types for which authorisation may be bypassed

the FIN system message types for which authorisation may be bypassed

the APC system message types for which authorisation may be bypassed.
The entitlement to modify messages has associated permissions indicating:

the message destinations that are allowed

the modification queues for which messages can be modified

the currency codes and amounts that are allowed

message types which are allowed (separate permissions are provided for FIN user message
types, FIN system message types, and APC system message types)

whether multiple retrieval of system messages is allowed

whether the use of the FINCopy service is allowed.

9.1.3 Message Approval


Overview
An operator with the necessary entitlements can use the Message Approval application:

to verify SWIFT MT messages held in the Message Verification queue

to authorise SWIFT messages held in the Message Authorisation queue

134 Security Guide


Controlling Message Processing

Verification of a SWIFT message involves re-entering sensitive or important items of data to


ensure that the message is accurate. Typically, any field that contains an amount must be
verified. Associated currency and value date fields must also be verified. Only messages that
are in SWIFT format require verification.
Authorisation is the process whereby a senior operator or Supervisor visually checks a message
before releasing it to the outbound network queue.

Entitlements
Operator profiles are used to control the use of all message verification and authorisation
functions. Entitlements may be granted or denied in relation to:

accessing the Message Approval application

approving, verifying, and authorising messages

disposing messages by bypassing message approval

the ability to route messages.


Some entitlements include permissions to enable operator access to functions to be further
restricted. The entitlement to approve messages has associated permissions indicating:

the message destinations that are allowed

whether messages can be verified

whether messages can be authorised

whether an operator can verify messages created or modified by that same operator

whether an operator can authorise messages created or modified by that same operator

whether a group of messages can be authorised without their details being viewed

the currency codes and amounts that are allowed

FIN user message types allowed

FIN system message types allowed

APC system message types allowed.


The entitlement to dispose message approval has associated permissions indicating:

the currency codes and amounts for which authorisation may be bypassed

the message types for which authorisation may be bypassed.


Messages input through the Application Interface may also be sent to the Verification or
Authorisation queue, for verification or authorisation within Alliance.

27 March 2015 135


Alliance Access 7.1 on Alliance Web Platform

9.1.4 Reactivating a Completed Message Instance


Overview
If necessary, you can reactivate a completed message instance which is no longer queued at a
routing point.
You can only do this if the message instance is not assigned to a unit, or if you are a member of
a unit to which the message instance is assigned and if your operator profile gives you the
entitlement to do it.
The re-activation scope is set by the security officers through the Security Definition application,
as follows:

Settings for the re-activation scope are:

Full, a message instance can be re-activated in all allowed routing and exit point.

Partial, a message instance can be re-activated in exit points only.

Restricted, a message instance can be re-activated in the Text Modification queue


(_MP_mod_text) for input messages, and the Modify After Reception queue
(_MP_mod_reception) for output messages.

Note An instance of an archived message cannot be reactivated.

9.2 Other Message Processing Controls


Introduction
When a message has been received by Alliance, it is processed, in some way or another by one
of the following applications:

SWIFT Interface application

SWIFT Support application

SWIFTNet Interface application

SWIFTNet Support application

Routing application

136 Security Guide


Controlling Message Processing

Message File application

Relationship Management application


In addition, the Monitoring application provides users with functions to monitor the status of LTs,
message partners, message queues, events, system resources, and the Alliance applications
and servers.
The System Administrator and security officers have the entitlement within the Monitoring
application to stop a particular process.

9.2.1 SWIFT Interface


Overview
The SWIFT Interface application provides the functionality required to send and receive MT
messages (FIN user messages and FIN/APC system messages) between Alliance and the
SWIFT FIN/APC application through SWIFTNet. Access to this application is normally granted
to all operators, although entitlements and permission must be allocated according to an
individual's operational responsibilities.
Standard SWIFT message authentication is performed on most MT messages sent to, and
received from SWIFT through the SWIFT Interface application.
SWIFT output messages that fail authentication are routed to the Reception Security
Modification queue. These messages may be viewed within the Message Modification
application where the cause of the failure can be investigated. A function is provided to "Bypass
Security" in exceptional situations for messages in the Reception Security Modification queue.

SWIFT Interface application


The SWIFT Interface application handles access control, destinations, and logical terminals
(LTs). One or more licensed destinations may be assigned to an operator - typically by
supervisory staff. The following entitlements may be granted or denied in relation to those
assigned destinations:

access to the SWIFT Interface application

perform Login/Select

monitor logical terminal status (Logout, Abort, Resume)

add, modify, or remove scheduled actions (such as logging on to APC, selecting FIN, and
sending messages)

modify choice of delivery subsets and request value date ordering

enable/disable automatic FIN Select or Logout from SWIFT

enable/disable re-connect

list own destinations

redefine delivery subsets

modify future subsets.


All other general facilities in this application (for example, view Logical Terminal details) are
available to operators once the entitlement to open this application is allowed.

27 March 2015 137


Alliance Access 7.1 on Alliance Web Platform

Note If a calendar has been created, then Login/Select can be scheduled to occur
automatically at specific times on specific days. Implementing automated Login/
Select may increase your system's vulnerability to a security breach. The physical
and logical security of your operating environment must be reviewed to
compensate for this potential increase of risk.

9.2.2 SWIFT Support


Overview
The SWIFT Support application provides a number of support functions related to the
configuration of logical terminals (LTs) and destinations, and the installation of Message Syntax
Tables and Message Standards. Access to this application is normally granted to supervisors
and to operators.
One or more licensed destinations may be assigned to each operator. The following
entitlements may then be granted or denied in relation to those assigned destinations:

access to the SWIFT Support application

add a new logical terminal, or

add, modify, or remove keywords related to the routing of messages

install a new Message Syntax Table

install Message Standards

Import/Export Message Templates

list own destinations

install/de-install/activate/deactivate Value-Added Services.


All other general facilities in this application (for example, view Logical Terminal status) are
available to operators once the entitlement to open this application is allowed.

9.2.3 SWIFTNet Interface


Overview
The SWIFTNet Interface application provides the functionality required to send and receive MX
messages (SWIFTStandards XML messages) or FileAct messages between Alliance and the
selected SWIFTNet service. Access to this application is normally granted to supervisors and
operators, although entitlements and permissions must be allocated according to an individual's
operational responsibilities.
The SWIFTNet Interface application is concerned with control of MX and/or FileAct message
traffic. Emission and reception profiles to manage the sending and receiving of MX and/or
FileAct messages can be set up and activated. The following entitlements may be granted or
denied in relation to emission and reception profiles:

access to the SWIFTNet Interface application

access to emission/reception profiles in view list based on allowed/prohibited Services or


Destinations

enable and disable emission and reception profiles

138 Security Guide


Controlling Message Processing

activate and deactivate emission and reception profiles

automatic/manual mode switch

add, modify, or remove scheduled actions (such as "activate" profile)

monitor session status

view and change SWIFTNet connection for profile

create, adopt, open, print, delete, and remove input channels.

Public Key Infrastructure


The authentication of messages is done with SWIFTNet Public Key Infrastructure, which is used
to guarantee the identity of the sender and the integrity of the message content. SWIFTNet
Public Key Infrastructure uses a system of private and public keys for calculating and verifying
PKI-based digital signatures. The signatures are calculated in the Hardware Security Module
(HSM) using the sender's private key and attached to the FIN message in the InterAct message
envelope. Authorisation is a separate process and this is handled by the Relationship
Management application. Except for the FINCopy service and test and training traffic, messages
cannot be sent between correspondents who do not have a relationship authorised in the
Relationship Management application.

9.2.4 SWIFTNet Support


Overview
The SWIFTNet Support application provides a number of support functions related to the
configuration of SWIFTNet Connections. Access to this application is normally granted to
supervisors and operators, although entitlements and permission must be allocated according to
an individual's operational responsibilities.
The following entitlements may be granted or denied in relation to SWIFTNet Connection
configuration:

access to the SWIFTNet Support application

add, modify, or remove SWIFTNet Connection

assign a SWIFTNet Connection

9.2.5 Routing
Overview
The Routing application enables operators to define all of the internal routing criteria necessary
for the correct processing and flow of messages within Alliance.
The ability to add and modify routing points and routing rules is normally limited to the System
Administrator and Supervisors or privileged operators. The security officers only have the
entitlement to open the application and approve new or modified routing schemas.
Within this application, the following entitlements may be granted or denied:

access to the Routing application

define a routing rule

add, modify, or remove a routing rule

27 March 2015 139


Alliance Access 7.1 on Alliance Web Platform

add, modify, or remove a routing point

add, modify, or remove a routing schema

add, modify, or remove a keyword

activate a routing schema

approve a routing schema.


All other general facilities in this application (for example, to view routing details) are available to
operators once the entitlement to open this application is allowed.

Note When an operator uses the CRnet Interface application to configure the details of a
customer application, the CRnet Interface automatically creates the required
message queues and the routing to and from those message queues. Therefore,
CRnet operators do not have to use the Routing application to configure CRnet
routing, but may use it for other routing purposes.

9.2.6 Message File


Overview
The Message File application provides users with a central query, maintenance, and archiving
facility for all messages processed by Alliance.
Within this application, the following entitlements may be granted or denied:

access to the Message File application

complete, move, or change the priority of a message instance

reassign or reactivate a message instance to another unit

depending of permission the ability to search the message file and hide messages of other
units

archive the Message File.


All other general facilities in this application (for example, to open the Message File and view
message instances) are available to operators once the entitlement to open this application is
allowed.
The entitlement to archive the Message File has associated permissions indicating:

whether an archiving schedule can be stored

whether archiving can be switched between manual and automated.


All CRnet File Transfers are stored in the Message File.

9.3 Application Interface Controls


Overview
This section is only relevant if your organisation is licensed to send and receive other types of
SWIFT message as well as CRnet messages.
The Application Interface enables operators to control the exchange of messages between
Alliance and various message partners using a variety of different connection methods.

140 Security Guide


Controlling Message Processing

Messages leave the Alliance environment through special routing points known as exit points.
Messages are input and output during sessions controlled by the Application Interface.
The systematic printing of messages is also performed through the Application Interface, for
sending messages to human message partners and to functional departments within a user's
organisation.
Access to the Application Interface is normally granted to all operators, who may start, run and
stop sessions and change the assignment of exit points to message partners. However, the
ability to create and modify the definitions of exit points, message partner profiles and
connection profiles, and to enable/disable message partners, must be reserved for the System
Administrator and Supervisors.
When receiving (pre-prepared) messages into Alliance, the following controls are implemented
to ensure the integrity of message traffic:

Local Session Authentication

Local Message Authentication

message validation

pre-defined connection points and file access controls

Session authentication
The CAS (Common Application Server) protocol enables remote hosts to open interactive
communications sessions with Alliance, to send and receive messages, through a local network
connection.
When attempting to establish a session, Session Authentication Keys may be defined which
prevent rogue systems from communicating with Alliance. The authentication mechanism used
is inherent within the CAS protocol.
Session Authentication Keys may be uni-directional or bi-directional and each key consists of
two parts. The permissions to display and update these keys in Alliance may be assigned to
different operators, if required.
Though not mandatory, the use of Session Authentication Keys for interactive CAS sessions is
highly recommended.

Local message authentication


A separate process may be used to authenticate each message input from, or output to, the
Application Interface, regardless of the underlying connection method used (for example CAS or
File Transfer). Local Authentication Keys (LAUs) may be defined and used to authenticate
messages sent to, and received from, message partners such as Mainframe systems.
The authentication mechanism used resembles that used for SWIFT message authentication.
An identical authentication mechanism must, of course, be available for use by that message
partner, using the same keys as those defined within Alliance.
Local Authentication Keys may be uni-directional or bi-directional and each key consists of two
parts. The permissions to display and update these keys in Alliance may be assigned to
different operators, if required.
For batch input/output, an authentication failure of one message causes the whole batch to be
aborted and an event to be generated and stored in the Event Journal.
Local Authentication Keys are optional (but recommended) for all connection methods. With
SWIFTNet Public Key Infrastructure for FIN, the connection between Alliance and the
SWIFTNet Link host must be secured, and a local authentication protocol can be used for this.

27 March 2015 141


Alliance Access 7.1 on Alliance Web Platform

Incoming message validation


For messages successfully input through the Application Interface, three different levels of
message validation may be performed:

Minimum (default): minimum validation and extraction of some keywords like currency or
amount, value date.

Medium: performs syntactical validation at the field level. It checks for the presence of
mandatory fields, keyword validation, limits, ranges of values, and so on. If, during
anInteractive session a message fails Medium validation, then a negative reply is generated
and sent to the message partner.

Maximum: performs the same validation as Medium. This level is provided for a possible
future level of message validation.

Pre-defined connection points and file access controls (UNIX only)


The controls provided in the Application Interface enable a Supervisor to pre-determine the
connection points to be used by particular message partners and the location and naming
convention to be used for input files.
When an operator runs a session, only these pre-defined parameters may be used.

Operator entitlements
When working with the Application Interface, the following entitlements and permissions may be
granted or denied:

access to the Application Interface

start/run/stop/abort sessions. Separate permissions may be granted to specify the allowed


message partners

create messages (by default, not granted to operators)

move messages to routing points (by default, not granted to operators)

view/print message partner profile. Separate permissions may be granted to view/print


session authentication and local authentication keys (by default, not granted to operators).

add/modify/remove message partner profile (by default, not granted to operators). Separate
permissions may be granted to update session authentication and local authentication keys.

add/modify/remove an exit point (by default, not granted to operators)

enable a message partner (by default, not granted to operators)


The entitlement to create messages has associated permissions indicating:

the message destinations that are allowed

the message types that are allowed

the currency codes and amounts that are allowed

the currency codes and amounts for which verification may be bypassed

the message types for which verification may be bypassed

the currency codes and amounts for which authorisation may be bypassed

the message types for which authorisation may be bypassed.

142 Security Guide


Controlling Message Processing

The default R7.1_MsgPartner profile that is assigned to message partners sets no constraints
on the messages that can be created. This profile can be modified to suit your own business
needs.

9.4 CRnet Interface Controls


Description
Access to this application is normally granted to all CRnet operators, who may start and stop the
CRnet component, open and close secure sessions with the Host System, hold and release
message queues, and enable and disable remote support.
The CRnet operator can also configure Host services and customer applications (although this
is more usually the responsibility of the System Administrator).
Normally, a CRnet workstation operator does not need direct access to Alliance, and only
communicates with Alliance through the GUI software installed on the workstation. The
workstation software communicates with Alliance, and uses the facilities provided by the CRnet
Interface application to exchange data with the Host System. The CRnet workstation operator's
access to Alliance applications and functions is therefore restricted to the facilities provided by
the workstation interface.

27 March 2015 143


Alliance Access 7.1 on Alliance Web Platform

Legal Notices
Copyright
SWIFT 2015. 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, 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.

144 Security Guide

S-ar putea să vă placă și