Recently there has been what is likely the beginning of a wave of break-ins and financial exfiltrations via the SWIFT Alliance. Reports vary a bit, but between vendor/operator mistakes, weak security controls, lack of integrated forensics, and some not-so-best practices we have ended up witnessing the theft of over $80 million dollars. (It could have been over $950 million dollars but for the successful identification of typos by some astute bank operators.)
I spent some time going through the SWIFT Alliance’s publication ‘Security Guidance for Alliance’ published on 18 March 2016 (current version is 29 April 2016) to understand what their baseline security recommendations and architecture are and then thought about how I would re-implement them to protect against some of the more malicious threats we are seeing today.
TLDR; the document is a fairly comprehensive approach to securing SWIFT against the types of attacks that were prevalent a decade ago. Times have changed, their model does not seem to have adapted to the threat landscape we are facing today. If you operate a SWIFT infrastructure or just find armchair quarterbacking and 20/20 hindsight to be fun to read – please continue! I’ll do my best to make this entertaining and hopefully informative.
1) Control your attack surface. “Users can access the Alliance Web Platform package using their standard browser. Alliance Web Platform will then interact with a back-end server (such as Alliance Access or Gateway) to provide the services requested by the user.”
According to this diagram the client browser uses HTTP-S, and according to the language there is no mention of only supporting strong cipher suites, disabling SSLv2, SSLv3, and TLS1.0, or protecting the Alliance Web Platform with a Web Application Firewall to terminate the sessions and provide a vehicle for administrative and high-value user monitoring, session recording, and forensics.
Recommendation: The Alliance Web Platform provides an interface that is accessed by operators and administrators from standard desktops. Administration needs to be gated to a specific set of Secure Administrative Workstations or virtual instances of them. These need to be recycled/rebuilt after each administrative session to prevent keystroke loggers from being deployed and they also need to force multi-factor authentication including geo-fencing/SrcIP.
All protocols used for administration and financial operations need to be forced to use TLS1.2 (current version at the time of this writing, obviously when it is superseded use the most current version) ONLY supporting the strong cipher-suites.
Looking at their architecture a bit more broadly (Wow, look a Forest!!!) I actually do not see a single network security device in the architecture besides an HSM and VPN edge device facing a public network. Part of reducing the attack surface is segregating and containing the SWIFT environment within a discrete security zone and then applying the most granular policy set possible to the infrastructure and applications that restricts access in every form to only those who need to have access to it. Short version – lets add appropriate policy enforcement at all edges and between nodes based on the minimum required transport protocol set.
2) Remember there is a network here. In the above Figure 3 from the SWIFT design guide you will note the rather obvious omission of any network switch or router. The protocols used are all IP enabled and there is no disclosed requirement for Layer-2 adjacency for message-passing or heartbeats in this architecture. As such the network elements should be factored into your architecture and not egregiously omitted.
Redraw your architecture with the switches, routers, firewalls, passive taps, monitoring tools, packet capture devices, into it. This is critical for understanding the actual threat landscape and attack vectors that will be used against your SWIFT environment.
If any of the devices are shared with other applications, servers, or provide transit services for other security zones this at a bare minimum should be identified and well understood and accepted by a separate risk team, but realistically should be physically and logically segregated from other applications even if they are deemed to be in the same tier of security zone.
Be certain to pay attention to often forgotten connections such as management and administrative networks that have been used to gain control over transit assets or to gain low-level access to servers to inject firmware or rootkits.
3) Browser Hygiene. “Packages running on Alliance Web Platform Server Embedded are thin-client GUI applications that only require Internet Explorer or Firefox on desktops.” Ok, seriously SWIFT just recommended Internet Explorer less than 60 days ago and didn’t mention Edge or Chrome. I will drop the mic here and avoid any further recommendations regarding the browser choices and recommendations for access – you all know better (I hope…)
4) Segment Authentication Systems of Record. “Alliance products support the usage of user ID/password, either locally stored (encrypted)or retrieved from LDAP or RADIUS enabled servers. Alliance products also support two-factor authentication by integrating with customer managed RADIUS enabled infrastructure. Such infrastructure then enables the use of a One-Time Password generated by a second factor, such as a hardware token, to connect to Alliance product family.”
I am glad SWIFT supports two-factor, this is a positive; but at the same time we now need to look closely at our domain architecture for LDAP and/or RADIUS. It has proven far too common for IT administrators to optimize on being able to swiftly (bad pun) add/delete/change accounts and thus consolidate all user account management into a single database, often based on Microsoft Active Directory. They will then integrate RADIUS or LDAP into their production AD user forest.
If you are proxying RADIUS/TACACS/LDAP to Microsoft AD take a two hour break, watch Armageddon, then visualize that the incoming planet-killer asteroid is every bad guy in the world launching phishing attacks at your users, getting their credentials, using script-kiddie tools to own an AD admin credential, granting themselves domain admin rights and making their new golden-ticket-issued account a member of the SWIFT Admin group (because I am sure you used an innocuous and deceptive name for that group too) and then issuing themselves a payday that made Bruce Willis and Ben Affleck look like paupers for saving the world in that blockbuster hit.
Once you are done watching the destruction of all mankind and crying a little bit when Bruce Willis saves Ben for his daughter Liv Tyler while Steven Tyler croons walk into your data center and disconnect your centralized authentication source from your SWIFT environment and please start segregating administrative and operator credentials.
5) Love your logs. But also realize you need better logging than the base O/S and application are likely to provide for you. Ensure you have put control points that capture DNS, IPFIX, Admin sessions access, Kerberos Ticket usage, etc at all ingress/egress points to each major component of the system, not just at a broad zone boundary.
Also recognize that if someone is taking the time to hack your system and they can make tens of millions of dollars on that payday they are probably smart enough to also have a run at your logging system. Ensure you love your logging and forensics systems as much as your applications and your capital reserves – segment the service dependencies there and ensure that even the administrators of the SWIFT environment do not have edit/delete access to the logs.
Bonus Points) Software/Image signing and verification. I don’t now about you but if I had a few billion dollars at stake I would ensure all of my software components I depended on in this system were signed properly and patches/versions were maintained current at all levels of the system: BIOS, Firmware, Infrastructure SW, Hypervisor, Crypto Libraries, Certificate Expiry, Admin Workstations, OS versions, Application Versions, etc. (etc, because I am sure I missed something and I am not intending the list to be comprehensive – am instead just trying to impress how full your stack actually is that you need to secure).
Ok, has this taken ten to fifteen minutes to digest? Or even as quickly as seven minutes? If so then you know what time it is: Time for a word from our sponsors!!!! Or, in Saturday morning cartoon speak, a brief commercial break where we get to see some Schoolhouse Rock and learn about Bills on Capitol Hill. (Warning: shameless product pitch ahead, skip to conclusion if I go overboard.)
Today in the SWIFT architecture there are many discrete components. Some are called out in the diagrams, some are implied, some seem to be forgotten or not given fair consideration in how they interact with the system. Each component has its own discrete attack surface: both physical and logical and spanning all tiers of the OSI stack.
In a SkySecure system our value is that we can collapse all of these into a trusted platform with internal, software provisioned, controls between each discrete system – you gain policy enforcement, full forensic level visibility, and full stack security.
The attacker now has to defeat controls that are ‘inside’ a trusted platform, reducing the threat surface of the controls themselves. Couple this with discrete application-layer visibility via advanced proxies and you can prove to any auditing source that your controls are functional and effective. Audit becomes a function of continuous monitoring and not a point-in-time event.
We execute internal workload threat surface monitoring, correlated to external attack surface permissions to also identify any potential application vulnerabilities or changes to workload attack surface – an indicator of CnC listeners.
In the SWIFT version there are many boxes and they do not depict a single policy enforcement point between them. This is beyond egregious. You only need to break one node in their architecture to have a lilypad to every other node. Break a central authentication store and you have unfettered access to everything.
If all components are within a SkySecure distributed system there is no place for an APT to hide without being detected – whether actively calling to a CnC or listening passively. We remove the persistence from APT.
/end_Commercial (that wasn’t too bad was it?)
Thanks for reading. We are hosting a forum on SWIFT Security at Microsoft’s office in New York on the Summer Solstice (good things will come to light). If this was interesting to you shoot me an email, leave a comment, fill out the exciting form below, or message me on Twitter and we’ll add you to our list for the event.
dg – @dgourlay