Control Definition
Control Objective: Reduce the cyber-attack surface of SWIFT-related components by performing system hardening.
In-scope components:
- dedicated and general-purpose operator PC
- jump server
- systems (physical or VMs) hosting a SWIFT-related component (including interface, GUI, SWIFT and customer connectors)
- local or remote (hosted or operated by a third party, or both) Virtualisation platform (also referred to as the hypervisor) hosting SWIFT-related VMs and their management PCs
- network devices protecting the secure zone
- [Advisory A1/A2/A3: Middleware server (such as an 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]
Note: SWIFT HSMs are FIPS 140-2 Level 3 compliant with hardened underlying OS and are out of the scope of this control.
Risk Drivers:
- excess attack surface
- exploitation of insecure system configuration
Implementation Guidance
Control Statement:
Security hardening is conducted and maintained on all in-scope components.
Control Context:
System hardening applies the security concept of “least privilege” to a system by disabling features and services that are not required for normal system operations. This process reduces the system capabilities, features, and protocols that a malicious person may use during 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).
- All in-scope systems are hardened, considering one or more of the following:
- vendor security configuration guidance
- industry-standard security configuration guidance (for example,24 CIS , DISA STIG, NIST)
- a local or regulator's standard security configuration, or controls set of the same rigour as the vendor or industry guidance
- The selected hardening configuration (set of rules) can be overruled by application-specific configuration requirements to maintain a proper operational state for SWIFT-related systems.
- At a minimum, the hardening process should do the following:
- Change default passwords.
- Disable or remove unnecessary user accounts.
- Disable or restrict unnecessary services, ports, and protocols.
- Remove unnecessary software.
- Restrict physical ports (for example, USBs) as appropriate.
- Set, when technically possible, auto-lock options (such as activating an operator PC screen saver requiring a login after an inactivity time-out or when turned to sleep mode). A 15-minute inactivity timeout is recommended.
- Adjust any default configurations known to be vulnerable. The vendor and industry standards listed above can provide detailed guidance to accomplish these minimum targets.
- Deviations from the selected hardening configuration are documented along with justification for the deviation and potential mitigations applied.
- Systems are maintained secure, as follows:
- by checking regularly (at least twice per year) the systems against the secure settings identified as per preceding guidance to take any relevant corrective actions
- by regularly applying the identified secure settings to the systems.
