Documente Academic
Documente Profesional
Documente Cultură
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
2 Security Guide
Table of Contents
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.
4 Security Guide
Training for SWIFT Users
Related courses
SWIFT recommends the following Alliance Access courses. For full descriptions, consult the
Training pages on swift.com:
27 March 2015 5
Alliance Access 7.1 on Alliance Web Platform
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.
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.
Related Training
If you are new to the role of Alliance Security Officer, then you may be interested in attending
the following training courses:
27 March 2015 7
Alliance Access 7.1 on Alliance Web Platform
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:
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
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.
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.
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.
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
File Transfer
MQ Workstation Internet
SOAP Explorer
Web Services Direct FileAct
Web Platform
ADK CAS
Monitoring
Message Management
Relationship Management
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.
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
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.
27 March 2015 13
Alliance Access 7.1 on Alliance Web Platform
Manage operator
profiles
Configure security
parameters and the use
of passwords
Approve routing
schemas
14 Security Guide
Security Aspects to Consider
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.
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.
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).
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.
16 Security Guide
Security Aspects to Consider
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.
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.
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.
18 Security Guide
Security Aspects to Consider
Alliance Web Platform host attacks due to third-party software weaknesses (because it is
accessible to a larger community, that is, the Internet)
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
Controls
Typical Alliance Web Access/Entry User Customer
Threat
attacks Platform Gateway infrastructure
Integrator
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
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.
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.
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.
27 March 2015 21
Alliance Access 7.1 on Alliance Web Platform
Remove software
System Management:
(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.
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:
logoff times
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:
inactivity time-out
password aging
terminal-dependent logon
27 March 2015 23
Alliance Access 7.1 on Alliance Web Platform
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).
Execute access (that run that file, assuming that the contents are executable)
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.
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:
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.
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.
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
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.
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.
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
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.
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:
27 March 2015 27
Alliance Access 7.1 on Alliance Web Platform
alter the limits set for CPU time, data segment size, core file size, and so on
access any device on the system (printer, terminal, modem, and so on)
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
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.
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
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.
30 Security Guide
Security Aspects to Consider
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.
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.
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:
27 March 2015 31
Alliance Access 7.1 on Alliance Web Platform
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.
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.
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.
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.
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.
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:
34 Security Guide
Security Aspects to Consider
Configuration
On Windows:
On Windows servers, the Installation application includes facilities that allow the system
administrator to:
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.
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.
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.
36 Security Guide
Installation, Upgrade, and Licensing
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:
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.
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).
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.
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.
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
Note Some parameters described in this section are only available if you have licensed
the relevant option for your system.
5.1.1 Activation
List of activation parameters
Parameter Description
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.
Default: 15
Minimum: 1
Maximum:120
Changes to this parameter take effect at the next login to Alliance Workstation.
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.
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.
Parameter Description
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 - 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
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 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 Windows: %ALLIANCE%\database\datafiles\JRNL
44 Security Guide
Configuration and Security 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
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.
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.
Parameter Description
Amount Specifies the convention used to separate decimals and units of a thousand:
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.
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.
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:
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:
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
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.
Minimum value: 1
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
BSS Path of Script Full pathname of the user-defined script that Alliance Access runs
File when an Alarm Event occurs.
It must be:
BSS Backup Specifies the type of digest that is calculated to ensure the integrity of
integrity archive backups.
Possible values are:
56 Security Guide
Configuration and Security Parameters
5.2.1.4 Message
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
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:
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:
Off
On
Default value: Off.
58 Security Guide
Configuration and Security Parameters
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
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:
27 March 2015 59
Alliance Access 7.1 on Alliance Web Platform
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:
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.
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
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
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
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.
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:
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
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
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:
Windows: C:\Alliance\Access\usrdata\report
5.2.1.8 RMA
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
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
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
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
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.
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
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.
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
Single
Multiple
Default value: Single.
Alliance Access must be restarted for changes to this parameter to
take effect.
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
68 Security Guide
User Management
6 User Management
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
6. If the user is authenticated successfully, then the user can log on using the permissions
assigned to him in Alliance Access.
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.
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.
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
Operator definition
The creation, modification, and approval of operator definitions are performed with the Security
Definition entity. Each operator definition defines:
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.
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)
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).
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.
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.
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
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.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.
defining and approving new units, and removing unapproved units only
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.
activating authorisations
revoking authorisations
accepting authorisations
rejecting authorisations
viewing authorisations
printing authorisations
creating authorisations
76 Security Guide
User Management
Note This role is only relevant if your organisation is licensed to send and receive other
SWIFT message types as well as CRnet messages.
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
adding or modifying correspondent and alias details in the Correspondent Information File
(CIF)
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:
modifying incoming and outgoing messages, except for messages in the Emission Security
Modification queue or Reception Security Modification queue
27 March 2015 77
Alliance Access 7.1 on Alliance Web Platform
managing entities
monitoring entities
configuring the Host services (although this is more usually the responsibility of the system
administrator)
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
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.
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).
Note Units are not applicable for CRnet (CREST) message traffic.
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.
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.
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:
82 Security Guide
User Management
must not consist of the same sequence of characters repeated two or more times - for
example, users must not use passwords such as swiftswift.
27 March 2015 83
Alliance Access 7.1 on Alliance Web Platform
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_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.
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.
86 Security Guide
Default Operator Profiles
WS Session 0 0 0 - 0 0 0
Timeout 0
Embedded None - - - - -
Checks
WS session None 0 0 - 0
timeout
control and monitor communication sessions between Alliance Access and a message
partner
27 March 2015 87
Alliance Access 7.1 on Alliance Web Platform
Session -
Authentication Key:
MT - None - - - None
(Allowed/Prohibited) prohibited prohibited
88 Security Guide
Default Operator Profiles
Session -
Authentication Key:
Session -
Authentication Key:
Session -
Authentication Key:
(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
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:
Remove None - -
Correspondent
27 March 2015 91
Alliance Access 7.1 on Alliance Web Platform
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.
92 Security Guide
Default Operator Profiles
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.
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
select a specific message and display its details - any fields to be verified are highlighted, but
blank
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:
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.
94 Security Guide
Default Operator Profiles
Final Approver
(Allowed/Prohibited)
27 March 2015 95
Alliance Access 7.1 on Alliance Web Platform
(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.
Open None - -
Application
96 Security Guide
Default Operator Profiles
27 March 2015 97
Alliance Access 7.1 on Alliance Web Platform
(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.
select one of several message modification queues and display a list of the messages held in
it
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
27 March 2015 99
Alliance Access 7.1 on Alliance Web Platform
(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.
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:
investigate message processing by searching the message instances stored in the Message
File. You can then display or print the search results.
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.
(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.
Bypass Approval No No - -
(Yes/No)
Answer Message Own None prohibited None prohibited None prohibited None prohibited
Destination(s)
(Allowed/
Prohibited)
Approve own No No - -
Actions
(Yes/No)
Bypass Approval No - No No
(Yes/No)
Bypass Approval No No - -
(Yes/No)
Export on None - -
Change
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)
Bypass Approval No No - -
(Yes/No)
Bypass Approval No No - -
(Yes/No)
(1) This parameter is only applicable for users of the Relationship Management package on the Alliance Web
Platform.
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.
Open Routing Point Routing Points - None prohibited None prohibited None prohibited
configure various system-wide security parameters, such as the number of days after which a
user password has to be changed
Approve Unit - - - -
(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.
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.
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
define which delivery queues in which SWIFT should store output messages in (known as
delivery subsets)
Login/Select... None -
Modify LT None -
Own Destination List List Own Destinations None None None None
(Allowed/Prohibited) prohibited prohibited prohibited prohibited
Enable LT None - -
Disable LT None - -
Remove LT None - -
Add LT None -
Remove LT None - -
Modify LT None -
(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.
modify the values for a large range of system parameters, such as time and date formats,
frequency of disk space checks, and so on
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)
define events that must be set as alarms, and set the distribution lists for these alarms
Mod Config. Param. Manage Encrypted Yes Yes Yes Yes Yes
(2) Parameters (Yes/
No)
Stop/Start None - -
Component
(2) An operator with this entitlement can update values for Integration Platform component-specific configuration
parameters using the Alliance Access Configuration GUI.
database corruption
software corruption
hardware failure
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.
back up archives
at server startup, if the security parameter, Software Check At Startup, is set to Yes
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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).
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.
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.
Message header
The Alliance header, which is separate from the actual message header, contains, among other
things:
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 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.
Entitlements
Operator profiles are used to control the use of all message creation functions. Entitlements
may be granted or denied in relation to:
completing messages
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 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.
Text Modification
Transmission Modification
Entitlements
Operator profiles are used to control the use of all message modification functions. Entitlements
may be granted or denied in relation to:
bypassing authentication for one or more messages in the Reception Security Modification
queue
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:
message types which are allowed (separate permissions are provided for FIN user message
types, FIN system message types, and APC system message types)
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:
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 for which authorisation may be bypassed
Full, a message instance can be re-activated in all allowed routing and exit point.
Routing application
perform Login/Select
add, modify, or remove scheduled actions (such as logging on to APC, selecting FIN, and
sending messages)
enable/disable re-connect
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.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:
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.
depending of permission the ability to search the message file and hide messages of other
units
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:
message validation
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.
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.
Operator entitlements
When working with the Application Interface, the following entitlements and permissions may be
granted or denied:
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.
the currency codes and amounts for which verification may be bypassed
the currency codes and amounts for which authorisation may be bypassed
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.
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.