Testing SWIFT systems in a more secure world

In a segregated, high-security environment, where access isn’t permitted without necessity, how can you perform security assessments that require ad-hoc access by other systems and security providers?

In the aftermath of the 2016 Bank of Bangladesh heist, the Society for Worldwide Interbank Financial Telecommunication (SWIFT) introduced its Customer Security Programme (CSP) to mandate the adoption of a Customer Security Controls Framework (CSCF).  As a result, any organization’s SWIFT Systems or SWIFT-related systems now exist segregated from general IT environment, locked away within a “secure zone”. Here, access is restricted to the systems required to facilitate message flow between internal banking systems and SWIFTNet. This robust security presents a challenge – how do you maintain an environment where so few have access?

In order to effectively perform a technical security assessment on a system or solution, security partners need direct access to the environment in which they exist. For application tests, this represents access to the application from their laptops (by connecting to the same environment), or to a remote system within the target environment where tools can be installed for use. The same is true for network security assessments.

Despite this fact, clear policies and processes implemented to facilitate effective security testing on SWIFT systems within the secure zone are uncommon. And whilst tailored workarounds can be created, they may be neither reliable long-term, nor scalable. This is because demand for them often comes unexpectedly in an organization’s time of need, thus also costing extra time and money.

Does SWIFT CSP permit access for security assessments?

Any secure environment can only be resilient to compromise if it is maintained. A catch-22 arises then when maintenance is required in an environment inaccessible to security partners. In our consultants’ own search for a solution, they began by unravelling the controls laid out in SWIFT’s CSP to understand the provider’s expectations and guidance. Of note are two controls in particular:
 

CSCFv2020 - 7.3A Penetration Testing

The requirement for technical security assessments is outlined within control 7.3A. This states that security assessments should be conducted against all “hardware, software, and network components” within the production environment, or within a pre-production environment that replicates the former. The main risk driver for this control: identification of “security vulnerabilities or security misconfigurations” that may facilitate or lead to a compromise.

By its very nature, this requires security providers to obtain temporary access to systems within the secure zone, and perform quality, in-depth security testing of the in-scope components. Without this access, reliable assurance of an organization’s security posture cannot be given. However, with components segregated so that nothing aside from down-stream systems can communicate with the secure zone, it may be incorrectly interpreted that access cannot be provided to said security providers.
 

CSCFv2020 - 1.1 SWIFT Environment Protection

The requirement to segregate SWIFT Systems from the general corporate IT network is outlined within control 1.1 of CSCFv2020. This states the requirement to “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”. The overall risk drivers for this control were the feasibility for a threat actor to gain unauthorised access to critical SWIFT systems via attacks which originate from the Internet or a compromise of the general corporate network.

The implementation guidelines for this control are extensive, but it states that “generally”, connectivity crossing the boundary of the secure zone should be restricted to:

• Bi-directional communications with back office applications and SWIFTNet
• Inbound communications from approved general-purpose operator PCs to the jump server
• Outbound administration data (data logging, backups, etc)

It further states that the inbound and outbound traffic should be limited “to the fullest extent possible”, and a process should be implemented to periodically review the “rules governing the connectivity”. An example – though not recommended – is the requirement to perform periodic vulnerability scanning, which in some environments may leverage scanning systems located outside of the secure zone. SWIFT acknowledges the possibility, and states that if the zone’s scanning systems are shared with the exterior enterprise environment “credentials used across the environment should be monitored to ensure they are only used when and where expected”.

As such, the creation of sensible policies and procedures which facilitate ad-hoc short-lived access to (or within) the secure zone for the purpose of completing technical security assessments, is not prohibited by the CSCF. As described, it is in fact required inherently, and encouraged in SWIFT’s own guidance outlined by control “7.3A - Penetration Testing”. 

The ideal solution for all is that a process be implemented which facilitates direct access to the secure zone for trusted partners to provide necessary security assessments. Rather than decreasing the robustness of the secure zone design, this increases its overall security posture by facilitating complete, comprehensive, and undisrupted technical security assessments. Through our own interactions with clients, the following two solutions have been found to effectively achieve this:
 

Direct access to services within the secure zone

Such direct access could be achieved through a process of introducing short-lived firewall rules that allow whitelisted “tester” devices either restricted or unrestricted access to select systems within the secure zone environment, such as web application interfaces and servers. Such whitelisting would apply only to the tester’s static IP and MAC address, thus facilitating testing and analysis from their own laptop. These firewall rules can then subsequently be removed once the assessment has concluded, in order to mitigate the risk introduced during the assessment timeframe. 
 

Access to a dedicated “testing” system connected to the secure zone

This could be achieved by creating a dedicated workstation with tools installed that the tester can access via Privileged Access Management (PAM) solutions. The workstation could exist within the secure zone, or within the organization’s server environment with ad-hoc whitelisted access to the secure zone. As a security precaution, this system could be “powered on” - or created, if virtualized - exactly when required, mitigating any risk associated with it being present within the environment day-to-day.

Access needn’t be granted to the production instance of the secure zone. It could instead (and ideally so) be to a pre-production instance that replicates the live production environment. This would facilitate the freedom to perform comprehensive testing without any risk of the assessment disrupting live traffic, or exposing the production environment to unnecessary risk.

The diagram below illustrates how the high-level solutions above fit into an existing SWIFT secure zone architecture:

Tester access requirements need to be considered when designing the SWIFT secure zone, or as a priority extension to one that exists already. With no ability to facilitate appropriate access to systems, SWIFT customers may find that they are unable to perform robust security testing in line with audit requirements, accurately assess risk, or indeed, fully understand the security posture of their most critical systems.

There are multiple solutions to facilitate access to components within scope of a security assessment. However, this will ultimately be determined by an organization’s architecture design and risk appetite. Once a solution is implemented, it is important that it is scrutinized, assessed from a security perspective, and well documented for audit, as it may likely become part of the secure zone’s security boundary.

It is important that SWIFT customers maintain the implementation of a robust and restricted secure zone, whilst also creating new policies, procedures, and - if necessary – infrastructure to enable comprehensive security assessments. Without a dedicated solution, organizations who engage external testing partners may likely find themselves losing time, money, and resource when the need for assessment arises.