With all the news about hacking banks and stealing money from banks over SWIFT, while the vulnerabilities weren't directly related to SWIFT, some questions arise:

  • Are software components of the SWIFT network certified by any external organization? Have they undergone rigorous security tests? (I'm worried they'd be available to a narrow audience, and may not be subject to enough scrutiny or security testing.)
  • Knowing that SWIFT was started many years ago, was the software architecture designed with security in mind?
  • Is the architecture available for security review?
  • I suspect like most banks/big corporations it's still running on 20+ year-old mainframes and the software is awful and while it was (hopefully) designed with security in mind I would't be surprised if there's a ton of vulnerabilities. – André Borie May 25 '16 at 3:57

Among other things, Swift is a cooperative organization of financial institutions who agree to using the same standardized messaging system for financial transactions. As such, they publicly promote the use of ISO 20022 as their primary standard for messaging between financial institutions. That said, each member may implement this standard using a very wide variety of software on different platforms each of which can have its own security vulnerabilities. The standard itself is a bit dated and probably could be improved, but the bigger issue creating vulnerabilities for financial institutions is each entity’s implementation and choice of security controls.

The ISO 20022 standard is accessible for review but each vendor’s implementation of it is probably not. As far as certification goes, these components would most likely be certified for ISO 20022 compatibility if anything, and not for security from an attacker’s perspective; so this is probably not something meaningful from the standpoint of your question.

I think it would be wise for the organization to create a more rigorous set of security standards which members must adhere too, possibly similar to but stronger than PCI-DSS, but I suspect there would be a lot of objections to this from member organizations that do not want the additional requirements. That said, I think you are bringing up very valid points and I think it would be very wise for organizations using Swift to put pressure on their peers to help address the security needs. More importantly, I think a lot of these member organizations are currently stuck using traditional security methods to fight much more high-tech adversaries. Now would be a great time for that organization to put a stronger emphasis on increasing the strength of its network to reduce future expenses related to breaches.

One thing that seems to also have emerged during the recent string of attacks is that SWIFT put out a request to all of the connected banks asking them to report potential breach information and cyber-attacks. As such it appears that SWIFT left a lot of the security responsibility in the hands of the individual banks and did not account for banks which would not perform appropriate security measures to defend the SWIFT network. Aspects of the attacks which have occurred may also imply that there is very little internal monitoring of SWIFT transactions from a purely fraud-detection standpoint. The following Reuters article points out that it appears that the relationships between banks is also fragile and that many of the weaker banks are unlikely to admit their security short-comings and that these short-comings may be somewhat common among all of the smaller banks participating in the network. Likewise the article goes on to talk about the importance of SWIFT participants to also increase their own non-SWIFT verification methods to add security to the less secure SWIFT process as such it would appear to imply that industry insiders don't have a lot of faith in the security of the SWIFT network and that it's a known risk in many ways.


Finally it should be noted that the ISO 20022 standard does not have much in the way of security within the standard itself. This is a very old communication standard without requirements for many modern security controls which would probably be required if a similar network were architected today.

| improve this answer | |
  • Good points, I was thinking that Alliance software package (Alliance Access/Gateway/Webstation...) were the only software used to communicate with SWIFT network, didn't know about vendor specific apps, or are you talking about apps that are built on top of Alliance software package? – Silverfox May 24 '16 at 16:40
  • 3rd parties like SAP and also a variety of payment processors in-house software. There's lots of stuff connecting to it directly and indirectly. More importantly there's a lack of strong security controls and monitoring around it. – Trey Blalock May 24 '16 at 17:55

It is important to remember that unlike many other protocols and methods for interconnection, SWIFT transactions are meant to run in a completely isolated environment (i.e. only over established, protected links between banks). Trusting the efficacy of the connection security might be a bad decision (failure of defense in depth), but at this point the "attacks on SWIFT" have constituted compromising a different, more vulnerable aspect of a bank's system (such as getting malware onto a banker's pc) and then using that breach as a pivot point to move toward the SWIFT system and execute theft using that access.

It would be akin to breaking into a bank vault (with typically great effort, but sometimes not) and then easily prying open all the little safe deposit box doors with a crowbar to obtain the haul: you could say the deposit boxes should be better protected to resist a simple elbow grease attack, but typically more effort is put into protecting access to the vault overall.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.