a) Overall design goals for implementing environment separation
- Implement a “secure zone” to separate and protect the local SWIFT infrastructure from the compromise of systems and services located outside of the secure zone.
- To the fullest extent possible, passwords and other authenticators that are usable inside the secure zone (especially for privileged accounts) are not stored or used in any form (hashed, encrypted, or plain text) in systems outside of the secure zone. This does not apply to encrypted back-up files. If the authentication services system resides outside of the SWIFT secure zone, then:
- Either the system is in another existing secure zone that has similar controls,
- or the system is only used to filter the connections to the SWIFT infrastructure component (controlling the connectivity at the boundary of the secure zone). In such a case, logical access to the SWIFT infrastructure component is ensured by another authentication mechanism residing in the secure zone (another IAM or the accessed component itself).
- The secure zone is appropriately scoped to each user's environment, including the potential reuse of existing secure zones (for example, a secure “production environment”, “back-office environment”, or “payment systems zone”) to include the local SWIFT infrastructure.
- The components within the secure zone are all protected to the same or an equivalent level of security, access control, and trust and may communicate freely within the zone. Primary purpose of a secure zone is to host SWIFT-related components but can also include non-SWIFT related systems which then also need to be adequately protected by applying controls applicable to the SWIFT-related components (see the CSP FAQ for the relevant controls).
- Appendix B contains illustrative architecture diagrams that show samples of the methods a secure zone can be designed.
b) Scope of the secure zone
- The secure zone contains, but is not limited to, all components of the local SWIFT infrastructure. This includes the messaging interface, the communication interface, the browser-based GUI, the SWIFTNet Link, the Hardware Security Module (HSM), the SWIFT connector, the jump server (see details below), and any applicable operator PCs solely dedicated to the operation or administration of the local SWIFT infrastructure.
- General-purpose operator PCs are not included in the secure zone.
- Dedicated operator PCs with SWIFT-related software installed (that is, "thick client" GUI software) are located in the secure zone, or the software is installed only on the jump server to be accessed by the general-purpose operator PCs outside of the secure zone.
- Back-office and middleware systems (for example, IBM® MQ servers) used for data exchange with back-office systems are not necessarily included in the secure zone, but may be considered for inclusion depending on the chosen size and scope of the secure zone.
- Test systems are not considered in scope of the security controls as long as (i) they are fully separated from production or live environment (including separate HSMs) and (ii) they are configured to only support test traffic (for example, by only using lite certificates on test-only logical terminals). If the test systems are not fully separated or can be configured for live traffic, then users must take the test systems in scope and make sure that the same security controls are applied as for production or live systems. Development systems are not within the secure zone and are not connected to the SWIFT network.
- The Alliance Connect SRX VPN boxes or the Alliance Connect Virtual VPN instances (hosting systems or machines) are in a secure environment with appropriate physical controls (aligned with control 3.1).
- The secure zone size and scope are defined in a way that is most appropriate to the user's environment. Options may include, but are not limited to the following:
- A SWIFT secure zone dedicated only for the local SWIFT infrastructure.
- An expansion of an existing secure area (for example, a secure “production environment” or “payment systems zone”) to include the local SWIFT infrastructure. The size and scope of this zone may vary significantly depending on the existing environment.
- Software, systems, and services within the secure zone are assessed for need and removed from the zone if not supporting the operations or security of the zone (for example, assess the need for e-mail access).
c) Protection of the secure zone
Boundary Protection
• Transport layer stateful firewalls are used to create logical separations at the boundary of the secure zone.
− Transport layer firewalls creating the secure zone boundary should be physically or virtually dedicated to the protection of the secure zone. If a firewall is shared to separate other zones, then care must be taken for the firewall management to make sure that compromises of the firewall do not affect the protection of the secure zone.
− Access control lists (ACLs) and application firewalls may be used to provide additional protection for the secure zone, but are not sufficient alone.
• Layer 2 devices (data link layer, such as switches) may be shared between the secure zone and other uses (VLAN separation).
• Administrative access to networking devices is protected using either an out-of-band network or through controlled in-band access (for example, a management VLAN). Administrative access to the firewalls that protect the secure zone does not rely on the enterprise user authentication system, but a system located within an existing secure zone that has similar controls as the SWIFT secure zone.
• Inbound and outbound connectivity for the secure zone is limited to the fullest extent possible. A process is implemented to analyse, review, and enforce the firewall rules governing the connectivity.
− No "allow any" firewall rules are implemented, and network flows are explicitly authorised (allow listing approach). To achieve this, a general enterprise server might initially be used to filter legitimate connectivity access towards the secure zone without losing traceability of such connections.
− Generally, connectivity crossing the secure zone boundary is restricted to bi-directional communications with back-office applications and MV-SIPN16, inbound communications from approved general-purpose operator PCs to the jump server, and outbound administration data (data logging, back-ups).
− Firewall rules are review ed annually, at least.
− Connections through the boundary firewalls are logged.
