SWIFT Attacks are Evolving - Is Your Segmentation Strategy?

Friday, April 28, 2017

Jesse McKenna

Bb41d7ba746e551cbae52d2aaab4f625

Not too long ago, very few people had heard of the Society for Worldwide Interbank Financial Telecommunication or SWIFT. The organization’s standardized message format has been adopted as the global standard for interbank financial transfers, and the associated software and messaging network drives the majority of international banking transfers today, in excess of five billion financial messages a year. However, this is not why most people have heard of SWIFT.

In recent years, reports of cyber attacks and fraud utilizing or compromising SWIFT applications have increased significantly. In 2016, the Bangladesh Central Bank and the New York Federal Reserve were involved in a cyber heist that netted $101 million - most of which has not been recovered. An additional $850 million would likely have been stolen if a typo in one of the transactions had not been noticed and questioned. Other attacks on the SWIFT network have since been reported in Vietnam, Ecuador, and Ukraine, though the majority of banks and countries affected by the dozens of breaches being investigated have not been made public.

Evolving Attack Strategies

Attacks on payment systems, including SWIFT, are nothing new. Financial institutions have been combatting fraud and theft since day one and attackers have kept pace with changing technologies to exploit vulnerabilities wherever they exist. A few years ago, the strategy of choice for attackers was to compromise a user’s computer and then submit fraudulent financial transactions “as the user.” This drove the prevalence of banking malware and remote access trojans (RATs) that were a primary concern for financial institutions. And although these strategies still exist and are a threat to individuals, businesses, and banks, awareness of these threats has led to better safeguards and a lowered success rate for criminals.

Not ones to back down from a challenge, attackers began shifting their attacks from the user endpoints to the applications and networks that drive the banking systems themselves. The significance of the attack on Bangladesh Central Bank, aside from the massive amount stolen, was the actual methods the attackers used. In addition to leveraging credentials stolen from authorized users, the attackers installed malware to prevent the payment system from giving the attacker’s presence away.

For example, there was a system in place where all transactions would be printed out so there would be a hard copy of all transaction records. To circumvent this, attackers disabled this process so that their fraudulent transactions would not be in plain sight on the printed copies. In the Vietnam heist, attackers modified the PDF reader used to track SWIFT transfers so that the fraudulent transfers would not appear.

In addition to disabling the printing of transaction records, malware was installed on the server hosting the SWIFT Alliance Software - a software stack built by SWIFT for managing and connecting to the larger SWIFT network. This malware was designed to decrypt various configuration files to search for specific terms and then subsequently bypass validity checks to avoid the transactions being spotted.

 

It’s obvious to see that these attacks are becoming more sophisticated, but they are also moving down the stack from the end users to the banking systems and safeguards that were previously beyond the reach of attackers.

 

Screen Shot 2017-04-13 at 2.45.53 PM.png

SWIFT Alliance Software Architecture

 

Distilling an Effective Defense

SWIFT has since released their Customer Security Programme which provides guidance to financial institutions for improving security protections around the Swift Alliance Software or any custom applications which interact with the SWIFT network. Although the guidance is a step in the right direction, actually securing a SWIFT application stack can be easier said than done as many components of SWIFT applications are typically legacy physical systems which don’t support newer security software, don’t receive security updates, and often exist in data centers struggling to adapt to new security protocols themselves.

There are a variety of security controls that go into securing banking applications - transaction monitoring, user behavior monitoring, anti-malware, and user security training to name but a few - but network security for SWIFT Alliance Software (or custom SWIFT applications) has traditionally been challenging to implement.  

Until recently, a best practice was to place the various SWIFT components in a firewalled zone, but this still allowed unfettered communication with any other workloads in that zone and provided no visibility or control above Layer 4. Clearly when dealing with adversaries who are skilled enough to compromise and exploit the very logic of the SWIFT applications themselves, a more nuanced approach is needed. The ideal solution would have three ingredients to effectively secure SWIFT application stacks:

 

  1. Microsegmentation for full visibility and control of all data center communications

  2. Ability to enforce security policies up through Layer 7 for a fine-grained and more effective policy construct

  3. Support across both virtual and physical workloads -- since many financial institutions still straddle both environments

 

Micro-segmenting the various components of the SWIFT application architecture ensures that only the appropriate endpoints and application components can communicate with each other and only over approved application protocols. Suddenly, if an attacker wanted to compromise your SWIFT application stack, they would need to do so using a vulnerability in a SWIFT application protocol and from another approved application component rather than simply gaining a foothold through an available port or protocol on the server running the SWIFT component. This is an extremely high barrier to entry for even the most skilled attacker.

Obviously there is no single silver bullet for protecting payment systems from fraud or cyber attacks. However, the ability to restrict the communications between the components of a payment system to only those that are required dramatically reduces the attack surfaces available to adversaries and provides far tighter controls than other approaches. As we continue to see attacks levied against banking and payment applications directly followed by the tightening of security best practices and cybersecurity regulations, the need for fine-grained visibility and control over all aspects of communication between system components will only rise.

About the author: Jesse McKenna is Director, Cybersecurity Product Management at vArmour. With over 12 years experience designing leading edge detection systems, he possesses deep expertise in fraud, security, behavioral analytics, and how theoretical detection and analytics concepts can be applied and operationalized in real world environments.

Possibly Related Articles:
41921
Cloud Security PCI DSS Firewalls
SWIFT security best practices cyber attacks
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.