Detailed Description Detailed Control Descriptions

4 Prevent Compromise of Credentials

4.1 Password Policy
A1 A2 A3 A4 B
Control Type: Mandatory Applies to architecture: ● ● ● ● ●

Control Definition
Control Objective: Ensure passwords are sufficiently resistant against common password attacks by
implementing and enforcing an effective password policy.

In-scope components:
Passwords defined on the following components:
• dedicated and general-purpose operator PCs
• jump server
• Swift-related components (including interfaces, GUI, Swift and customer connectors, new HSM)
• systems hosting Swift-related components
• network devices protecting the secure zone
• on-premiseslocal or remote (that is hosted or operated by a third party, or both) virtualisation or cloud
platform hosting Swift-related VMs and their management PCs
• personal tokens and personal mobile devices used as possession factor for multi-factor authentication
(considered as software tokens) (see control 4.2)
• [Advisory: bridging servers (such asother Mmiddleware or file transfer servers other than customer
connectors) used for and guardian of the data exchange between back-office and Swift-related
components]

Risk Drivers:
• password cracking, guessing, or other computational compromise

Implementation Guidance
Control Statement:
All application and operating system accounts enforce passwords with appropriate parameters such as length,
complexity, validity, and the number of failed login attempts. Similarly, personal tokens and mobile devices
enforce passwords or a Personal Identification Number (PIN) with appropriate parameters.

Control Context:
Implementing a password policy that protects against common password attacks (for example, guessing and
brute force) is effective for protecting against account compromise. Attackers often use the privileges of a
compromised account to move laterally within an environment and progress the attack. Another risk is the
compromise of local authentication keys to tamper with the integrity of transactions.
However, it is important to recognise that passwords alone are generally not sufficient in the current cyber-threat
landscape. Users should consider this control in close relationship with the multi-factor authentication
requirement.

Implementation Guidelines:
The implementation guidelines are common methods to apply the relevant control. The guidelines are a
helpful way to begin an assessment but should never be considered as an audit checklist as each user’s
implementation may vary. Therefore, in cases where some implementation guidelines elements are not
present or partially covered, mitigations as well as particular environment specificities must be
considered to properly assess the overall compliance adherence level (as per the suggested guidelines
or as per the alternatives).

07 July 2023 74
Detailed Description Detailed Control Descriptions

• A password policy that also covers PIN settings is established, aligned to current industry standards or
industry best practices, and defines the following criteria:
− password expiration
− password length, composition, complexity, and other restrictions
− password re-use
− lock out after failed authentication attempts (and remedy)
− password requirements modified as necessary for the following specific use cases:
o in combination with a second factor (for example, one-time password)
o authentication target (for example, operating system, application, mobile device, or token)
o type of account (general operator, privileged operator, application-to-application account, or local
authentication keys)
For additional best practice guidelines about password and PIN parameter settings, see Swift Knowledge
Centre articles 5021567 and 5022038.
• The password policy is developed in consideration of known password-based vulnerabilities in the
computing environment. For example, requiring a password of 15 or more characters for Windows
systems prevents Windows from computing the highly vulnerable LAN Manager (LM) password hash.
• The established password policy is enforced through technical means (for example, through an Active
Directory group policy, or within application settings), when possible.
• Effectiveness of the password policy is reviewed regularly (annually, by recommendation).
• System settings related to password management and storage are aligned to industry and vendor best
practices (for example, enabling the “NoLMHash” registry setting in Windows).
• Passwords used for secure zone systems are significantly more exposed if the passwords are stored in
authentication systems outside of the secure zone (for example, an enterprise Active Directory). Instead,
passwords for secure zone systems are, to the fullest extent possible, stored only within the zone (for
example, in an Active Directory for production systems) as described in the guidance for the design of the
secure zone or another existing secure zone that has similar controls.

Optional Enhancement:
• Apply the control to all bridging servers (such as middleware or file transfer servers other than customer
connectors) used for data exchange between back-office and Swift-related components.

Note: Users should implement strong passwords and preferably strong authentication mechanisms for all
systems used within the end-to-end transaction chain, and not limit these controls to the Swift infrastructure only.

07 July 2023 75
Detailed Description Detailed Control Descriptions

4.2 Multi-Factor Authentication

A1 A2 A3 A4 B
Control Type: Mandatory Applies to architecture: ● ● ● ● ●

Control Definition
Control Objective: Prevent that a compromise of a single authentication factor allows access into Swift-related
systems or applications by implementing multi-factor authentication.

In-scope components (depending on implementation):

• dedicated operator PC login
• access to jump server and to new HSM
• login process to the messaging interface (including a related hosted database), communication interface,
Swift and customer connector (including a related hosted database) or a service provider or outsourcing
agent Swift-related application
• login process to (operating) systems hosting the messaging interface (including a hosted database), Swift
and customer connector (including a related hosted database) and communication interface or a service
provider or outsourcing agent Swift-related application
• access to the remote Swift infrastructure (that is hosted or operated by a third party, or both)

Risk Drivers:
• credential replay
• password cracking, guessing, or other computational compromise
• password theft

Implementation Guidance
Control Statement:
Multi-factor authentication is used for interactive user access to Swift-related components or applications and
operating system accounts.

Control Context:
Multi-factor authentication requires the presentation of two or more of the following common authentication
factors:
• knowledge factor: something the operator knows (for example, a password)
• possession factor: something the operator has (for example, connected USB tokens or smart cards, or
disconnected tokens such as a (time based) one-time password- (T)OTP- generator or application storing
a cryptographic private key that runs on another device like operator’s mobile phone considered as a
software token, RSA token, 3-Skey Digital and its mobile version considered as a software token, or
Digipass)
• inherence factor: something the operator is (for example, biometrics such as fingerprints, retina scans, or
voice recognition)
Implementing multi-factor authentication provides an additional layer of protection against common authentication
attacks (for example, shoulder surfing, password re-use, or weak passwords) and provides further protection from
account compromises for malicious transaction processing. Attackers often use the privileges of a compromised
account to move laterally within an environment and to progress an attack.

Implementation Guidelines:
The implementation guidelines are common methods to apply the relevant control. The guidelines are a
helpful way to begin an assessment but should never be considered as an audit checklist as each user’s
implementation may vary. Therefore, in cases where some implementation guidelines elements are not
present or partially covered, mitigations as well as particular environment specificities must be
considered to properly assess the overall compliance adherence level (as per the suggested guidelines
or as per the alternatives).

07 July 2023 76
Detailed Description Detailed Control Descriptions

• When implementing multi-factor authentication, the following principles apply:

− When based on a knowledge factor (typically a password) combined with a possession factor (a mobile
device), the device used for the second factor must not be the same as the device used to enter the
first factor. As such, using an app to generate the second factor on the same device/PC used to enter
the first factor (password) is not sufficient to access the user’slocal Swift systems.
o Second factor solutions based on a possession factor include (but are not limited to) TOTP, RSA
SecurID, Digipass, Mobile App, Transaction Authentication Number (TAN) Table, 3-Skey Digital
and its mobile version, and personal USB token. The solution should be selected per the user's risk
management, considering NIST SP 800-63B Authenticator Assurance Level 2 as guidance).
− An inherence factor is more safely combined with a possession factor than with a knowledge factor.
• Multi-factor authentication is implemented on one authentication stage/step (at minimum) encountered by
the system administrator or the end user when accessing a Swift application, the new HSM or the hosting
system.
− Operating system administrators when accessing the hosting system or new HSM:
o at the secure zone boundary (jump server)
o at the dedicated operator PC login (within the secure zone)
− End users (in descending order of security robustness) when accessing the Swift application or new
HSM:
o on the individual Swift applications (the browser-based GUI, the messaging interface, or the
communication interface)
o at the secure zone boundary (jump server)
o at the dedicated operator PC login (that is, within the secure zone)
• Multi-factor authentication is implemented for remote user administrative access, generally for VPN
authentication.
• Multi-factor authentication systems are significantly more exposed if the authentication credentials are
stored outside of the secure zone (for example, within an enterprise Active Directory). If possible, then the
authentication system that supports the multi-factor solution is located within the secure zone.
• The presented authentication factors are individually assigned and support the individual accountability of
access to services, operating systems, and applications.
• If single sign-on (for example, SAML) is implemented, then a second factor is still required at the login or
at a later stage.
• When accessing (at least for transaction processing 41) a Swift-related service, application, or component
that is operated by a service provider or a third party (such as a service bureau, a Business Connect or
an L2BA provider, or an outsourcing agent), multi-factor authentication must be used.

Note: All Swift and Swift-compatible third-party vendor messaging and communication interfaces must support or
embed multi-factor authentication.

Considerations for alternative implementations:

When the device used for the second factor is the same as the one used to enter the first factor, additional
mitigations must be identified and implemented in line with a user risk assessment (considering NIST SP 800-63B
SP Authenticator Assurance Level 2 as guidance)
The objective of the risk assessment is to evaluate and keep potential risks under user’s risk appetite when
combining factors in case of loss, theft or compromise of such device. Mitigations can include technical measures
(such as enforcing a PIN or a password to unlock an application linked with the registered device, application that
generates a one-time string; limiting the accessed functions depending on the device level of trust; requiring
additional factor, such as a biometric factor to unlock cryptographic private key(s) used as possession factor, for
most sensitive functions,…) and include as well complementary procedural requirements (such as Policy asking
end user to immediately contact a security operations centre -SOC- to block, potentially remote-wipe, or put on-
hold any potential access or transaction performed through this lost, stolen or potentially compromised device).

41
such as creating, submitting, approving, or modifying transactions or user entitlements.

07 July 2023 77