SWIFT Messaging Is Under Fire – Is There Any Truth in It?

19 Apr
2016

SWIFT Messaging Is Under Fire – Is There Any Truth in It?

Identity Protection firms that are currently criticizing the SWIFT messaging system are being opportunistic. The SWIFT messaging standard only deals with passing information among banks to facilitate financial transactions—billions of dollars a day. SWIFT was not designed to address authentication and access controls of the networks themselves. If these ID Protection firms are trying to make a case, it should be that authentication is needed to access the networks that pass SWIFT messages. Is there actually a data security issue with SWIFT messaging—or is it with the IT systems that generate them? As with every system that transmits, stores, or receives financial information, there are always multiple risks of data theft.

Current Read on SWIFT Security

The SWIFT messaging system operates in closed loop, private networks, which is the sole basis of its security. It uses a very simplistic, open standard for communicating financial transactions among banks worldwide. SWIFT messages are not even encrypted, the premise being that only authorized processes and people can send and receive SWIFT Messages. However, since SWIFT is an open standard, determining how SWIFT works and what the messages mean is very simple for hackers. They know exactly how to identify messages and interpret their financial significance. All they need is access to the SWIFT network, which is unfortunately easily gained by, for example, spear phishing bank employees followed by a malware injection into a bank’s systems.

Hackers Are Focused on Malware Infiltration

Using malware to open up back doors in the SWIFT messaging network, hackers have access to the systems that produce and process SWIFT messages. By intercepting and deciphering the messages for these multi-million dollar financial transfers, hackers can, with minimal effort, capitalize on altering the SWIFT messages to redirect funds to their own off-shore shell accounts.  This is the business of malware, an aspect that SWIFT was never designed to detect or prevent.

Improper Controls in Place for Identifying Malware Infections

After researching SWIFT, there does not seem to be many guarantees of security outside of the use of closed loop and private networks. Using malware installed on the banking systems, hackers have been able to breach the messaging system and redirect financial transactions. Recently, for example, a Bangladesh bank had at least $80 million redirected from the bank’s account at the Federal Reserve to money-laundering accounts in the Philippines and other countries. According to a report on the breach from Fortune magazine, “attackers took control of the bank’s network, stole credentials for sending SWIFT messages and used sophisticated malicious software to attack the computers it uses to process and authorize transactions”. According to a second Fortune article, the New York Fed stated that “the payment instructions in question were fully authenticated by the SWIFT messaging system in accordance with standard authentication protocols.” This breach and theft really points to improper controls for identifying malware infections in conjunction with a very open and widely used protocol for financial messaging.

Stopping Malware Should Be First Priority

Now, let’s really think about the problem and the solution. The ID Protection firms are touting multi-factor authentication (MFA) as the silver bullet for securing SWIFT. But that only secures access to the “supposedly closed” network that carries SWIFT messages. The problem that needs to be solved first is to put controls in place to make sure systems that have access to financial information are at as little risk of being infected by malware as possible. Second to ensure that sensitive data is not present when the inevitable breach by malware occurs.

Constantly Evolving Malware Avoids Security Controls

The MFA solution that ID Protection firms are providing does not have any impact on a system that has been infected with malware.  The purpose of malware is to avoid authentication and access control systems, so it’s my belief that neither 2FA (2 Factor Authentication) or MFA have any impact on SWIFT messaging security beyond guarding network access. Malware kits sold on the Dark Web are constantly evolving to avoid detection, target weak spots in security, and work in conjunction with sophisticated social engineering ploys to infect any system with valuable data.

Remove the Temptation with Tokenization

In summary, the SWIFT messaging standard deals with passing information – not authentication and access controls.  If ID Protection firms are trying to make a case, it should be that two-factor authentication is needed to access the private networks that pass the SWIFT messages. While malware will continue to be a challenge to defeat, a common sense approach is to ensure that when an infection does occur, there is no valuable data to steal.

Remove Toxic Data

The most efficient way to accomplish this feat is to remove sensitive data from financial IT and business systems completely and replace the data with functional tokens to use in business processes. Removing valuable data eliminates the entire reason to infiltrate a system with malware. If there is nothing to steal, there is no temptation to hack—there are plenty of other targets from which to choose.

Financial institutions use tokenization to not only remove payment card information (PCI) but also to keep passwords, account numbers, and personally identifiable information out of the reach of hackers. The first step in injecting malware is often to steal employee login credentials. Tokenizing security credentials and all other sensitive data is a fundamental first step in stopping malware infections that can lead to devastating financial losses like the SWIFT hacks.

TokenEx is the industry leading cloud tokenization platform. For more information on how to remove toxic data from your environment, while maintaining full control contact sales@tokenex.com or visit TokenEx.com