Control Definition
Control Objective: Protect physically and logically the repository of recorded passwords.
In-scope components:
Repository recording accounts and passwords defined on the following components:
- dedicated and general-purpose operator PC
- jump server
- SWIFT-related components (including interfaces, GUI, SWIFT and customer connectors)
- systems or virtual machines hosting SWIFT-related components
- HSM and related tokens
- network devices protecting the secure zone
- local or remote (hosted or operated by a third party, or both) virtualisation platform (also referred to as the hypervisor) hosting SWIFT-related VMs
- [Advisory A1/A2/A3: Middleware server (such as IBM® MQ server or similar) used for data exchange between back-office and SWIFT-related components]
- [Advisory A4: other Middleware server (such as an IBM® MQ server or similar) than customer connector used for data exchange between back-office and SWIFT-related components]
- SWIFTNet Online Operations Manager (O2M) on swift.com
Risk Drivers:
Implementation Guidance
Control Statement:
Recorded passwords are stored in a protected physical or logical location, with access restricted on a need-to know basis.
Control Context:
The secure storage of recorded passwords (repository) makes sure that passwords are not easily accessible to others, thereby protecting against simple password theft. Common unsecure methods include, but are not limited to: recording passwords in a spreadsheet or a text document saved in cleartext on a desktop, or in a shared
directory, or a server, saved on a mobile phone, written/printed on a post-it or a leaflet.
This control covers the storage of emergency, privileged or any other account passwords. All accounts have to be considered because (i) combination of compromised, not-privileged, accounts, such as transaction creator account and approver account can be damageable, and (ii) even monitoring accounts provide valuable information during the reconnaissance time.
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).
- Passwords written on physical media are protected through:
- placing inside a sealed, tamper-evident security envelope
- storing in a safe
- logging the access to the storage location and which account passwords have been accessed.
- Passwords stored logically (digitally) are protected through:
- Encryption-at-rest or obfuscation (that is, no plain text storage),
- Authenticated access to the storage location, ideally with access logging.
- Passwords are not recorded in user manuals or other operational means unless the password is stored in line with the guidance above.
- If emergency access is granted to an operator who, under normal conditions, would not have access, then the password is changed immediately thereafter, and optionally, also the combination to the storage safe.
- Passwords are not hardcoded in scripts or other software code.
Optional Enhancement:
The safe is certified through, for example, Underwriters Laboratories (UL) Class TL or EN-1143-1 certification.
