d) Access to the secure zone systems
d.1 Local Operator (end user and administrator) Access
• The secure zone has implemented one of the following designs for restricting operator access (interactive or command-line sessions) into the secure zone:
− Operators connect from dedicated operator PCs located within the secure zone (that is, PCs located within the secure zone, and used only for secure zone purposes).
− Operators connect from their general-purpose operator PC to the secure zone through a jump server (for example, using a Citrix-type solution or Microsoft Terminal Server) located within the SWIFT secure zone or within another existing secure zone that has similar controls. As the entry point into the secure zone, the jump server implements strong security practices, including the following:
o Make sure all in-scope security controls in this document are implemented (for example security updates, system hardening).
o Separate jump server for system administrators (with multi-factor authentication) and end users. As an alternative to separate jump servers, only allow temporary access to system administrators with effective approval processes and session activity recording.
o Restrict access to authorised operators only.
o Remove any unnecessary software.
o Restrict risky activity (for example, sending or receiving e-mails).
o Enable logging.
− Operators connect from their general-purpose operator PC and only access the messaging or communication interface with a browser-based GUI (for example, Alliance Web Platform). The following specific security controls apply to this set-up:
o The browser-based GUI is located in the secure zone and is logically separated from the messaging and communication interface.
o Multi-factor authentication is implemented, where appropriate (on the browser-based GUI, on the messaging interface, or on the communication interface).
o This set-up cannot be used for operating system administration activities.
• SWIFT systems within the secure zone restrict administrative access to only expected ports, protocols, and originating IPs.
d.2 Remote Operator Access (teleworking, “on-call” duties, or remote administration)
• Remote access to the secure zone from outside of the local user network first requires VPN authentication (recommended with multi-factor authentication) to the local network before accessing the secure zone through the same secured channels as local operators.
• A risk assessment is performed by the user to consider appropriate security controls to be implemented for remote access, such as the use of a virtual desktop infrastructure, dedicated channels for connectivity (for example, dedicated jump servers for remote users, leased lines).
e) Separation from General Enterprise IT Services
• To protect the secure zone from credential theft or a compromise of enterprise authentication (LDAP, RADIUS, Identity Provider, multi-factor) services, or a combination of both, secure zone systems use a separate authentication system from the general enterprise authentication service. For example, secure zone systems are not a member of the corporate directory service, but are instead members of a secure zone directory service.
• Supporting IT infrastructure, such as asset management, databases, data storage, security services (for example, patching), and networking services (for example, DNS, NTP) used within the secure zone is protected from credential compromise within the larger enterprise. Institutions must conduct an analysis of connectivity points which make sure that these systems do not store authenticators (passwords, tokens, and other methods) for systems and accounts in scope in any format (hashed, encrypted, plain text)
outside of the secure zone or another existing secure zone that has similar controls. The supporting IT infrastructure should not be exclusive to SWIFT systems and may be shared within the secure zones.
Optional Enhancements:
• Systems within the secure zone implement (when technically possible) application allow listing, which allows only trusted applications to be executed.
• Restrict (through additional separation) the communication between components of the secure zone considering the following:
− Network ACLs or host-based firewalls that restrict traffic on a host-by-host basis within the secure zone.
− Individual hardware or network-based firewalls between the components in the secure zone can optionally be used.
Considerations for alternative implementations:
Institutions with a high level of security programme maturity within the organisation might consider implementing alternative controls such as those suggested below or others. The alternative solutions must be risk-appropriate to each environment, and must consider the effort required to effectively implement, manage, and maintain the solution.
• Not separating secure zone authentication services from the enterprise authentication service will require implementing a comprehensive set of defence-in-depth controls to protect from and detect adversaries that cross the secure zone boundary. Controls may include locating the authentication service within an existing secure zone with similar controls as those applicable to the SWIFT secure zone, limiting trust relationships between the larger enterprise environment and the secure zone (such as one-way trust
relationships), restricting operator and administrative access, implementing strong privileged access controls, implementing read-only access where feasible, enabling verbose logging, and implementing centralised active monitoring and detective capabilities.
• If general enterprise IT services (for example, vulnerability scanning and boundary firewall management) are shared between the secure zone and other environments, then any credentials used across the environment should be monitored to make sure they are only used when and where expected.
• If a general enterprise server is initially used to reach the secure zone, then that server is only used to filter legitimate connectivity access (as a concentrator or gateway to ease access filtering to the secure zone). Identity and access management for secure zone components or the jump server (or both) stillrely on authentication services that reside within the SWIFT secure zone or another existing secure zone that has similar controls.
• If the secure zone has dependencies on enterprise shared functions (such as directory services, servers, or networks) that are outside the scope, then the user must make sure that any compromise of such functions will not compromise the security of the in-scope components.
