Ensuring effective security control of your SWIFT payment environment

SWIFT messages encapsulate billions of financial transactions made annually around the world. Beyond complying with the SWIFT Customer Security Programme (CSP), organizations must design and implement adequate security controls to defend SWIFT users against the significant risks posed by threat actors.



Stéphane Hurtaud - Partner - Cyber Security Leader - Deloitte

Yasser Aboukir - Senior Manager - Cyber Risk Services - Deloitte

Leopold Stiegler - Senior Consultant - Cyber Risk Services - Deloitte

Published on 29 April 2021

Share this article


The Society for Worldwide Interbank Financial Telecommunication (SWIFT) is one of the most widely used electronic payment messaging systems in the world. Whether it is for core business activities or secondary payment transactions, having a SWIFT infrastructure has non-negligible requirements and risks, as well as obligations set forth by SWIFT themselves.

To help limit the opportunities that cyber criminals have to exploit weaknesses in SWIFT users' local environments in the future, SWIFT has created the Customer Security Programme (CSP). The SWIFT CSP is organized around the Customer Security Control Framework (CSFC) which requires adherence to specific controls’ objectives. This consistent set of controls establishing a secure baseline for the SWIFT community, in line with information security industry standards and based on SWIFT's analysis of cyber threat intelligence, aims to guide organizations to "secure their environment", "know and limit access", and "detect and respond".

Within the SWIFT CSP there are a number of activities that can be performed to help improve the overall security position of a SWIFT environment and its related components, as well as to further validate the effectiveness of these security controls. Such activities include penetration testing activities (c.f. control 7.3A Penetration Testing), red teaming, security configuration assessments, privileged access, and security architecture reviews, etc.

A little concept

As part of its mandatory security objectives, the main SWIFT components should be within a SWIFT-secure zone segregated from the rest of the corporate network with additional security requirements. These requirements range from a strict whitelisting approach at the firewall level, to stringent network segregation, clearly defined access controls, operating system and application server hardening, user and privileged access management (least-privilege), and other supporting controls that contribute to meeting these security objectives.

If implemented according to the mandatory security objectives set out by SWIFT, the SWIFT environment can be split into the following functional sections (depending on the local SWIFT footprint):

The complex interaction between the different components of the secure zone, the back office, supporting components, and the business and IT administration work flows can expose the environment to a number of internal and external risks that need to be addressed with both technical and non-technical controls. Each aspect of the security controls act as a layer of defense; therefore, it is important that the security controls are implemented adequately and in a logical manner. Furthermore, the implementation of the aforementioned controls are impacted by the context of the organization and its business requirements.

Inherent risks on local SWIFT networks

High profile cyberattacks have highlighted that an organization’s SWIFT environment can be a profitable target for cyber criminals. With over 11,000 SWIFT users operating in more than 200 countries, each with a varying degree of cyber security maturity, the potential financial loss is in its millions. The damage caused by such cyber risks is limited only by the organization’s available credit lines and means to monitor and retrieve unauthorized transactions.

Whether the attack is performed by a sophisticated threat actor or an internal organization (e.g. employees colluding together for profit), there are many threat vectors affected by the organization’s industry and country. There are, among others, three general scenarios to be considered:

Threat vector


External attack

The external footprint of an organization or its Internet-facing assets often receive the most attention from both the organization and the attackers, as anyone can access these resources and attempt to compromise them.

Attack vectors such as social engineering or spear-phishing could be effective means of gaining entry into the organization’s internal network. Organizations where shadow IT exists may also open themselves up to external threat actors if an Internet-facing server is put into production without following internal processes and procedures, or where a server has been forgotten and fallen out of the patching lifecycle.

Internal attack

Depending on the implementation and the link between the secure zone and the back office applications that manage and handle transactions, it may not be necessary to compromise the secure zone to send unauthorized SWIFT messages.

The risk of an internal attack is especially prevalent in the case of the non-exhaustive scenarios such as:

  • There is an issue with the overall design of the architecture/infrastructure, enabling unauthorized access or the bypassing of security controls;
  • The implementation is not in line with the initial design, either through controls not being implemented correctly, sufficiently, or through misconfigurations;
  • Inadequate OS-level or application-level hardening, such as hardening not based on vendor-specific or community-driven good practices for hardening;
  • Missing controls in governance related processes such as the provision and assignment of users with access to SWIFT-related components or the timely revocation thereof;
  • Inadequate configuration of permissions/roles, enabling users with multiple roles to potentially perform actions without 4-eye approval;
  • Permissive firewall rules due to insufficient periodic review of firewall rules and lack of governance related to rule changes.

Insider attack

The human factor remains a considerable security risk in cyber/IT security. Much in the sense of “quis custodiet ipsos custodes?", or in this context, who monitors the monitors?; it is those tasked with designing, implementing, and maintaining the security controls, who are often in the best position to disrupt or bypass these controls. This is applicable for both the IT administrators and the business end-users, where the former can attempt to bypass implemented technical controls, and the latter can potentially subvert business imperatives. These actions may not necessarily be intentional, neither fueled by personal financial gain or as a hostage of circumstance, but can be triggered by social engineering, even leaving the victim initially unaware of the consequences of their actions. In this regard, cyber security is a topic beyond just the department, and awareness of cyber security related topics is key.

During our previous red teaming or penetration testing engagements on SWIFT environments, we have demonstrated the plausibility of some of these scenarios. In particular, leveraging social engineering techniques and abusing external systems connected to SWIFT remain important attack patterns to consider.

Illustrative Cyber Kill Chain

The Cyber Kill Chain is an industry model designed to help understand how an attacker may conduct a sequence of activities to cause harm to an organization (e.g. from infiltrating a network to exfiltrate data from it). An effective understanding of the Cyber Kill Chain assists information security professionals in establishing strong controls and countermeasures to protect their organization's assets. The Cyber Kill Chain example provided here shows the targeting of an organization’s local SWIFT network initiated by a spear-phishing against SWIFT operators until the attacker gains the ability to send a SWIFT message.


Vigilance is key

The SWIFT infrastructure and its supporting components represent a complex system with many moving parts. In order to fend off potential cyberattacks, it is imperative that organizations have a clear understanding of all aspects of the SWIFT CSP and are able to securely implement its requirements. The following general recommendations can form a baseline to assure the security of the SWIFT environments:

  • Implemented controls should reflect the nature of the organization and its business requirements/limitations while still satisfying the security objectives of SWIFT;
  • Implemented controls should be verified by technical tests for their operating effectiveness and whether they were implemented correctly/fully;
  • Independent technical-level assessments of these controls can help gain an external perspective on how the controls were implemented, and provide potential improvements to further reduce the risk of compromise;
  • While the SWIFT security objectives focus mainly on the secure zone, the associated components outside the secure zone can also be compromised to the same effect than a secure zone compromise (e.g. unauthorized transactions). Depending on your sector, you should consider following advisory controls from the SWIFT Customer Security Control Framework, especially 2.4 A Back Office Data Flow Security.
  • Finally, the human factor must be considered and regular security awareness sessions should be conducted for all staff members, including role-specific training for SWIFT operators with privileged access.

Share #DeloitteInsideNow


SWIFT Customer Security Programme

Banking information is some of the most important to keep safe. That's why recent high-profile cyber-attacks on customers using Society for Worldwide Interbank Financial Telecommunications (SWIFT) are so significant. Deloitte can help business leaders navigate the factors associated with implementing SWIFT's Customer Security Controls Framework (CSCF), as well as address SWIFT dependencies.

© 2021. See Terms of Use for more information. Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. Please see to learn more about our global network of member firms. The Luxembourg member firm of Deloitte Touche Tohmatsu Limited Privacy Statement notice may be found at