Control Definition
Control Objective: Ensure the confidentiality, integrity, and mutual authenticity of data flows between local or remote SWIFT infrastructure components and the back-office first hops they connect to.
In-scope components:
- Data exchange layer: flows of financial transactions between the local or remote (hosted or operated by a third party, or both) SWIFT-related components (interfaces, GUI or SWIFT and customer connectors) and the back-office first hops at the application level they are connected to (directly or through middleware).
Risk Drivers:
- loss of sensitive data confidentiality
- loss of sensitive data integrity
- unauthenticated system traffic
Implementation Guidance
Control Statement:
Confidentiality, integrity, and authentication mechanisms (at system, transport or message level) are implemented to protect data flows between SWIFT infrastructure components and the back-office first hops they connect to.
Control Context:
Protection of data flows or connections between the back-office first hops (at the application level) as seen from the SWIFT or customer secure zone and the SWIFT infrastructure safeguards against person-in-the-middle attack, unintended disclosure, modification, and data access while in transit.
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).
- Data flowing between local or remote (hosted or operated by a third party, or both) SWIFT-related components (such as interfaces or connectors) and the back-office systems (or middleware systems) they are directly connected to, is protected using a secure mechanism (for example, LAU in combination with a confidentiality protection, or another message-based authentication solution, XML DSIG, AES GCM Authenticated Encryption, or two-way TLS) that provides confidentiality, integrity, and mutual authentication of the data in transit. This includes the data flow between the following:
- messaging interface and the first back-office (or middleware) hops as seen from the interface
- communication interface and the first back-office (or middleware) hops as seen from the interface
- connector and first back-office (or middleware) hops as seen from the connector
- Secure protocols use current, commonly accepted cryptographic algorithms (for example, AES25 or ECDHE26) with key lengths in line with the current best practices. For more information about cryptographic algorithms that support secure protocols, see SWIFT Knowledge Base article 5021566.
- As this control is expected to become Mandatory gradually in a future release, the following guidelines are already provided to progressively reach compliance:
- Possess an inventory of data flows between SWIFT-related components and the first back-office (or middleware) hops.
- Possess a plan to implement/activate secure mechanisms for identified flows, considering the following:
- Implement secure mechanisms (see the first guideline above) as exposed by the interfaces, connectors, or middleware server.
- Migrate opportunistically legacy and less standard flows to secure mechanisms or protocols.
- Mitigate (in the interim) the risk of back-office host spoofing or message injections through systems or network connectivity means.
- When a middleware server is used for data exchange with the back-office systems, some requirements are expected on the middleware server supporting hosts. Those hosts are the wardens of the data exchanged between the back office and the SWIFT-related components, as follows:
- Irrespective of where the middleware server hosts are located and shared with, the same security requirements apply to those hosts, such as channelled MQ servers used to reach a back-office first hop, as for other SWIFT-related components or infrastructure systems. Those security requirements cover the location in another secure zone that has similar controls as those applying to the SWIFT or customer secure zone, privileged access restrictions, login and password policy, installation of security updates, and restriction of internet access. Those controls have the middleware server identified as Advisory in the “In-scope components” of the control definition.
- Protection of the data on the middleware servers (such as data present in the queues of MQ servers used to reach the back-office first hops) must be ensured to prevent unauthorised access. This can be done by implementing thorough access controls or by encrypting queues or data at rest.
- Protection of the SWIFT-related data that flows between the middleware server hosts (such as between several channelled MQ servers) should be safeguarded as part of the middleware infrastructure protection by using secure mechanisms (see the first item of the implementation guidelines above).
- Definition and management of the connectivity rules and business flows on the middleware servers must be secured to prevent unauthorised flows.
- For middleware servers (such as IBM® MQ) that directly connect SWIFT infrastructure components, it is advised to also implement the same level of protection on the flows between this middleware server and the back-office first hops as seen from an application perspective by the SWIFT-related component. To gradually reach control compliance for those links, the following guidelines are provided:
- Possess an inventory of SWIFT-related data flows between the middleware server and the back-office first hops as seen from SWIFT-related component.
- Possess a plan to activate secure mechanisms for identified flows, considering the following:
- Implement secure mechanisms (see the first item of the implementation guidelines above) as exposed by the middleware server or the back-office system.
- Migrate opportunistically legacy and less standard flows to secure mechanisms or protocols.
- Safeguard (in the interim) the authentication of the data sources and authorisation of the SWIFT related data through native middleware functionalities or through systems or network connectivity means that prevent host spoofing.
- Credentials and private keys used, and usually stored, by the applications to secure the flows are protected (large spectrum of protection, from proper coding guidelines to usage of specific solutions, can be envisaged based on user’s risk management).
Note: SWIFT expects this control to become Mandatory in a future version of this document and will phase the following expectations:
- middleware servers (to start, when used)
- flows between the middleware servers and the SWIFT-related components
- SWIFT-related flows towards the back-office systems reached by the SWIFT-related components directly or through the middleware server (to finish)
