Two years ago, few outside of the major financial institutions had heard of the Society for Worldwide Interbank Financial Telecommunication (SWIFT). It’s a global organization that enables its financial sector members (more than 11,000, by last count) to arrange for financial transactions between them. Then, in early 2016, thieves infiltrated the Bank of Bangladesh’s SWIFT interface and used it to transfer $81 million overseas, where it disappeared before investigators could catch up with it. Only a typo prevented the thieves from making off with nearly $1 billion.
As dozens more attempts to target SWIFT deployments around the world have surfaced, banks and security teams have gotten increasingly focused on the threat to SWIFT systems.
In this series of posts, I’m going to discuss this threat and how SWIFT customers and their partners can most effectively approach the looming combination of security risks and compliance concerns that they now face.
The State Of Play
Of all the many intrusions targeting SWIFT deployments in recent months, some have been stopped, but others have not. Links have emerged between several of the intrusions and state-sponsored criminal operators based in North Korea, meaning that banks face nation-state resources when protecting their systems.
And on the heels of those discoveries, a new dump of classified information purports to contain evidence of a widespread exploitation of a SWIFT service bureau in the middle east by the NSA. Service bureaus provide SWIFT messaging services for third-party banks that don’t want to stand up (and secure) their own SWIFT infrastructure. They’re generally seen as a smart security and efficiency measure by smaller banks, but this is another reminder that they’re also a single point of failure: if your service bureau isn’t secure, you aren’t secure.
This isn’t even the first time that third-party SWIFT services have been targeted. Buried in the string of SWIFT breaches from 2016 and 2017 are several where service bureaus were used to reach the SWIFT messages of their client banks. In one instance, the targeting of a third-party service used by Tien Phong Bank in Vietnam was enough to make that bank reassess their security posture and bring their SWIFT infrastructure in-house.
If you need to defend against SWIFT targeting, you need to defend against lateral spread.
There have been dozens of reported attempts to target SWIFT deployments, both for espionage and criminal means. If there has been any common denominator to these attacks, though, it is that these intrusions rely on lateral spread. In virtually all of the cases reported so far, the intruders have compromised the environment well beyond SWIFT, capturing credentials to allow them to access SWIFT, and sniffing network details to enable them to operate without detection.
SWIFT has not sat idly by as these breaches have piled up. After several strong public statements, SWIFT released a new set of security controls for SWIFT customers in late 2016. More recently, SWIFT has also commented on the “responsibility” of service bureaus to keep their customers’ data safe. SWIFT customers are expected to self-attest to meeting the mandatory controls by late 2017, and SWIFT has announced that they will begin audits to validate these self-attestations as early as 2018.
THE SWIFT Security Controls
Note that these controls apply to SWIFT customers that run their own local SWIFT services. Many financial institutions choose instead to contract with a third-party cloud service, called a “service bureau,” to manage their SWIFT infrastructure (SWIFT maintains a list of certified service bureaus).
If you contract with a SWIFT service bureau for some or all of your SWIFT infrastructure, then you should review and apply the SWIFT security controls to your internal infrastructure, and separately review the security posture of the service bureau that you work with.
The controls run the gamut of steps that every organizations should take to protect their high value applications, and they include 27 distinct controls – 16 of which are mandatory. I’m going to focus here on the mandatory controls.
You can read through each control on SWIFT’s website, but it might be helpful to group the mandatory controls into the following six categories:
- Segment your SWIFT application and control access and data flow into and through the application itself. (1.1 – 2.1)
- Keep your SWIFT application servers and infrastructure updated and patched. (2.2 – 2.3)
- Secure user access to your SWIFT application, both logically and physically. (3.1-5.2)
- Defend against malware and data integrity threats. (6.1-6.3)
- Monitor, analyze, and prioritize the security alerts this should generate. (6.4)
- Prepare your organization to watch for and respond to threats. (7.1-7.2)
These controls are well-tailored to the increasing threat that we have seen. This means that by adapting your compliance to the threat you face, most organizations should be able to kill two birds with one stone: meet SWIFT’s 2018 deadline, and protect yourself against the increased SWIFT targeting we’re seeing in the wild. Blindly applying these controls, however, is not the best approach.
It’s critical that when evaluating and complying with these controls, organizations first take stock of the threat they face and the nature of their own SWIFT deployment. For example, building an application dependency map of your SWIFT deployment and the applications that it relies upon is a vital first step to understanding your deployments exposure and how to secure that exposure. Developing this information, along with an assessment of the third-party services that you rely on, is critical for to understand how best to use these controls not just to check the compliance box, but to actually increase the security of your SWIFT infrastructure.
With compliance deadlines looming, and the pace of SWIFT-targeting by criminal and intelligence elements seeming to keep increasing, the question of how to comply with these controls in a way that most improves the security of your SWIFT deployment is a critical issue today. In my next post, I will dig into this question in more detail, discussing how SWIFT customers should analyze the threat environment and their own SWIFT deployment, and what lessons those inquiries can offer for organizations looking to comply with the SWIFT controls.
If you’re a SWIFT customer, the clock is ticking on meeting SWIFT’s 2018 audit timeline for the new cybersecurity controls. While the controls map well to the new threats facing SWIFT customers, you’ll need time to assess the controls against your environment and comply with them in the most secure way.
If you use a SWIFT service bureau, recent disclosures about service bureau targeting is a clear reminder that trusting in a third party service doesn’t remove risk – it just shifts it. If you’re going to trust your SWIFT processing to a third party service, ensure that it’s a SWIFT-certified service bureau, and make sure to review their security policies. If the service bureau isn’t segmenting your data from their other customers, or doesn’t have other important security protocols in place, you might be better off elsewhere.