Deception Technology – Locking Down Banking and the SWIFT Network
Over the past several years, banks using the Society for World Interbank Financial Telecommunication (SWIFT) financial network have continued to be the victim of ongoing cyber attacks. This is not to say that the SWIFT network has any explicit vulnerabilities, more that the bank network in which SWIFT is being used may have vulnerabilities that allow attackers to do the reconnaissance necessary to penetrate and perpetuate using that particular bank’s SWIFT access.
SWIFT message formats were originally developed by SWIFT and then subsequently codified as ISO standards (ISO 15022). This includes well-defined definitions for system messages, customer payments and checks, financial institution transfers, treasury markets, collection and cash letters, securities markets, treasury markets – metals and syndication, documentary credits and guarantees, traveler’s cheques, and cash management – customer status.
SWIFT Application Program Interfaces (APIs)
SWIFT also includes application program interfaces (APIs) so that financial institutions can integrate SWIFT transactions with other applications systems. This includes the SWIFT Integration API, which enables financial institutions to deploy their own custom code to the SWIFT Alliance Access Integration Platform (IPLA) or the SWIFT Integration Layer (SIL). Also included is the SWIFTRef API, which provides an automated look-up service for important SWIFTRef data. Finally, there is an Alliance Access Developer Kit, which allows further access to resources and services of SWIFT Alliance Access. The SWIFT APIs may be internally cyber resilient and well designed, but failures in an individual bank’s cybersecurity protections can allow cyber attackers unintended access to the data and command syntax moving into, and out of, these API access points. Once again, SWIFT is well designed, but individual banks have many vulnerabilities that may, in turn, result in SWIFT transaction compromise.
Most of us in banking and cybersecurity recall the massive attacks leveraging the SWIFT networks just a few years ago. Banks in Ukraine, the Philippines, Vietnam, Bangladesh, and Ecuador in aggregate have lost more than $100 million in targeted attacks. In order to achieve these goals, the attackers had to penetrate the target bank’s networks, set up detailed reconnaissance such that they could watch the flow and authentication of every SWIFT transaction in that bank, and use their newly gained understanding of that flow to set up fraudulent transactions. Once the transaction was done, the money was wired through a series of institutions in a way designed to “wash,” or hide, the money by obfuscating the transaction flow, ultimately resulting in cash withdrawal from vulnerable banking systems.
SWIFT Customer Security Programme
In response to this, the SWIFT network published updates to its Customer Security Programme and the associated Security Controls Framework. Members are required to comply with the updated framework as published in April 2019 or so. This must happen with self-certification by the end of 2019, which is almost here as this blog is being written.
There are many mandatory security controls, including those that focus on:
- Operator session confidentiality and integrity for the operating sessions connecting to the local infrastructure;
- Identifying known vulnerabilities within the local SWIFT environment by implementing a regular vulnerability scanning process and then acting upon the results;
- Physical and logical password storage providing for the protection of recorded passwords.
There are also new voluntary best practices that include:
- Securing virtualization platforms and virtual machines hosting SWIFT-related components to the same level as physical systems;
- Application hardening such that the attack surface of SWIFT-related infrastructure is reduced by performing hardening on the SWIFT messaging and communications interfaces and related applications.
Most important, SWIFT stresses the use of multi-factor authentication under the CSP. MFA is now a required SWIFT best practice for financial institutions and will generally require two factors that might be something you know such as a pin or password, something you have such as a hardware token or mobile phone, or something you are such as a biometric.The CSP certainly raises the bar on cyber defense in banking institutions that use the SWIFT network, but cannot by itself stop a sophisticated and determined attacker. Any application system used by a bank, including SWIFT, would be at risk to an attacker that can easily move undetected laterally through networks and interlope on bank processes and privileged user activity.
Acalvio ShadowPlex raises the bar even higher on would-be SWIFT attackers
Acalvio ShadowPlex lets you raise the bar even higher on would-be SWIFT attackers. Acalvio ShadowPlex allows you to deploy a virtual minefield of decoys to surround and protect your bank’s application infrastructure. By wrapping SWIFT assets with a cloak of deception decoys, you raise the probability that even the most sophisticated cyber attackers will be identified and stopped before they can access your SWIFT network and perpetuate the fraudulent transfer of funds.
Find out more about Acalvio and how deception technology can help you reduce risk and maintain compliance. We’d be pleased to introduce you to our latest technology and share information about customers that have used Acalvio ShadowPlex to protect the most sensitive enterprise and government networks.
Authors
