Editorial & Advertiser Disclosure Global Banking And Finance Review is an independent publisher which offers News, information, Analysis, Opinion, Press Releases, Reviews, Research reports covering various economies, industries, products, services and companies. The content available on globalbankingandfinance.com is sourced by a mixture of different methods which is not limited to content produced and supplied by various staff writers, journalists, freelancers, individuals, organizations, companies, PR agencies Sponsored Posts etc. The information available on this website is purely for educational and informational purposes only. We cannot guarantee the accuracy or applicability of any of the information provided at globalbankingandfinance.com with respect to your individual or personal circumstances. Please seek professional advice from a qualified professional before making any financial decisions. Globalbankingandfinance.com also links to various third party websites and we cannot guarantee the accuracy or applicability of the information provided by third party websites. Links from various articles on our site to third party websites are a mixture of non-sponsored links and sponsored links. Only a very small fraction of the links which point to external websites are affiliate links. Some of the links which you may click on our website may link to various products and services from our partners who may compensate us if you buy a service or product or fill a form or install an app. This will not incur additional cost to you. A very few articles on our website are sponsored posts or paid advertorials. These are marked as sponsored posts at the bottom of each post. For avoidance of any doubts and to make it easier for you to differentiate sponsored or non-sponsored articles or links, you may consider all articles on our site or all links to external websites as sponsored . Please note that some of the services or products which we talk about carry a high level of risk and may not be suitable for everyone. These may be complex services or products and we request the readers to consider this purely from an educational standpoint. The information provided on this website is general in nature. Global Banking & Finance Review expressly disclaims any liability without any limitation which may arise directly or indirectly from the use of such information.


By David Higgins, Director of Customer Development, EMEA, CyberArk

The SWIFT network should be considered a part of our critical infrastructure. It is fundamental to the flow of money around the world, enabling 11,000+ financial institutions to send and receive information about financial transactions in a secure, standardised and reliable environment.

In recent times, however, users of the SWIFT network have been targeted by cybercriminals. With one successful heist having the potential to open the tap on millions of pounds, attackers are looking for any way in. In the last two years, we’ve seen three publicised breaches of organisations utilising the SWIFT network; the most notorious being the Bangladesh Central Bank where attackers made away with $81 million.

The anatomy of a SWIFT attack

Just like any other advanced cyberattack, the route to the crown jewels (in this case the SWIFT-connected systems) is by exploiting privileged accounts. After breaking through the perimeter, the attackers can start looking for credentials to move to another area of the network. Using stolen privileged credentials, they can then escalate privileges and move laterally through the host environment until they reach the lucrative SWIFT-connected systems.

In the case of the Bangladesh bank heist, this was the stage where the attackers started monitoring what the administrators and users of those systems were doing, so they could start to make requests. They also noticed that each time a transaction was issued, it would be sent to the printer too. Using exploited credentials, the attackers disabled the printer, helping them to remain undetected as they issued false transactional requests.

The SWIFT response

While the SWIFT network has not been compromised, its users have been, so SWIFT has responded with a robust Customer Security Programme. Some elements are advisory and some are mandatory, but, in total, there are 27 controls to be implemented across the community by January 2018. Not all SWIFT customers will need to adhere to all 27 controls. It all depends on the architecture they have; determining this will be the first step to understanding which of these controls they need to follow to get compliant.

Prioritising privilege

Across the 27 controls, whether they are mandatory or advisory, privilege is a common theme. Attackers are looking to perform lateral movement and exploit systems connected to the SWIFT network, and privilege is the path to do that. As the countdown to SWIFT security compliance begins, financial institutions need to recognise the scope of privilege is far broader than simply ‘credential management’ and address it in the following three ways:

  • Lock down credentials: First, it’s about identifying privileged accounts within the SWIFT environment and locking down credentials. ‘Credentials’ isn’t just passwords; there can also be credentials used within applications or SSH keys. One of SWIFT’s required controls talks about managing your administrative level credentials, so let’s say you secure the root password on all your unix devices. If your administrators have SSH keys that they’re using to authenticate this route then you’ve not actually achieved compliance – your administrators will simply bypass that control with SSH keys.
  • Isolate and control: Once you’ve locked credentials down, you need to isolate and control privileged sessions. By introducing a session broker and monitoring those sessions, you can start to understand what administrators and users of the systems are doing. It’s no longer just a case of managing credentials, rotating passwords and making sure that they’re set to a strong value; it’s also about looking at the admin rights and the entitlements users have to get on the systems. If you’ve got a highly privileged account, for example a domain administrator account that can connect to all the Windows servers within your SWIFT secure zone, the attackers are going to target that account. They know if they compromise that one account they’ve got admin access to the organisation’s entire Windows infrastructure. If you were to give out least privilege (i.e. non-administrative access) to the users, and it’s a non-admin account that’s compromised, it makes the attacker’s journey far more difficult.
  • Continual monitoring: Financial institutions need to be able to spot when attackers are trying to exploit credentials and perform behaviour analytics around these users. We know the types of accounts which will be a target for attackers, so putting some detection around their behavior will allow us to spot abnormal patterns when it comes to privileged users.

In this highly secure environment, financial institutions need to make sure they’re giving the right users the right access at the right time. By making sure privileged activity is locked, monitored and trusted, it will not only be far more difficult for attackers to get into the SWIFT environment in the first place, but any insider threats will quickly be detected and stopped in their tracks.