Complying with the SWIFT Security Controls Framework May Be Harder Than You Think

In my previous blog I briefly explained the new SWIFT regulations framework that will come into force on January 1st, 2018. In this blog I will focus on what is required to meet the first SWIFT requirement: “Restrict Internet Access & Protect Critical Systems from General IT Environment”. I will also explain how GuardiCore can help in complying with these requirements faster, simpler and in a more robust and maintainable way.

This requirement is designed to create a clear and controlled boundary between SWIFT components and all other components in the network (general IT). In a very detailed implementation guidance document, SWIFT explains what is meant by that and how SWIFT expects its customers to implement this requirement along with the components that should be part of the SWIFT secure zone.

Just to name a few of those guidances:

  • Inbound and outbound connectivity for the secure zone is limited to the fullest extent possible.
  • Transport layer stateful firewalls are used to create logical separation at the boundary of the secure zone.
  • No “allow any” firewall rules are implemented, and all network flows are explicitly authorised.
  • Firewall rules are reviewed at least annually.
  • Operators connect from dedicated operator PCs located within the secure zone (that is, PCs located within the secure zone, and used only for secure zone purposes).
  • SWIFT systems within the secure zone restrict administrative access to only expected ports, protocols, and originating IPs.

SWIFT also recommends to implement internal segmentation between components in the secure zone to even further reduce the risk.

Now let’s take some time to understand what complying with this paragraph (just one out of sixteen) requires from the administrator.

1. First you will need to identify all the components that belong to a secure zone along with all their connections. This mapping is far from being trivial. The number of SWIFT related components in a big financial institution can reach tens and hundreds of components, some physical and some virtual and hosted on different types of infrastructure. We usually see people using firewall logs, NetFlow and other “manual” mapping methods which are time consuming,  prone to error and tedious. A good visibility tool is a must when going through such a process.

2. Once all the components are mapped and all the connections between them and to the outside world are clear, the SWIFT guidance dictates that every flow that is crossing such a boundary be clearly understood and authorized. Again without a good visibility tool this can be a very long procedure. Application owners, system administrators and network architects will need to provide input to figure out that “This machine connects to an outside server on this 63422 port, because it is a BES client, the IBM monitoring software that is built into some of the images” – true story.

And we are talking hundreds of such examples. A tool that visually shows on a map machine names rather than IP addresses; processes, user-names and application paths such as  “/opt/BESClient/bin/BESClient” instead of random high ports makes this process fast, simple and reproducible.

Visualization of above mentioned flow in GuardiCore Reveal map.

3. Next, after all the mapping has been done, the administrator will have to actually implement the segmentation and enforcement of the policy in line with the regulation. Well, this can become quite tricky. The naive approach of putting all machines in the SWIFT secure zone in a separate VLAN can prove quite a difficult task, as you will need to go and configure switches on different infrastructures (some virtual ,some physical). This will require involving different people in the organisation and cutting those tickets can take weeks.

The plot thickens even more – the components may be physically spread around different locations and teams; any change across the network such as a new operator PC added to the pool (due to a business requirement) or a machine migrates from VMware to OpenStack means you need to do this all over again. This this will lead, over time, to holes and issues in auditing procedures. But what if the tool that you used for mapping could also help you set the policy in a logical way saying “All operator PCs can only talk to SWIFT connectors on only this port”? Now, move the Operator PC to OpenStack, add one more to the pool, keep the tag on it and the policy will be enforced automatically. I think this is the only sane way to go.

4. Last, but not least, during auditing times when all the data needs to be presented to the auditor, if you are not using one single tool to do it all, the audit may take much more longer – going over different switches, firewalls, etc., to prove segregation and that “every flow is authorized.”

Given the complexity and dynamic nature of modern IT, a seemingly simple task of “putting a border around my secure zone” can become a real headache if you don’t have the right tools in place. GuardiCore Centra is the platform that provides the right level of visibility, allows you to build simple and maintainable policy, enforce it, and pass audits easily – across any infrastructure at any scale.

When Looking for SWIFT Audit Guidelines, Beware of the Customer Security Controls Framework

In March 2017 SWIFT published its new Customer Security Controls Framework to the community. This is the first time SWIFT is publishing such security guidance and they announced that they will start auditing compliance with those requirements from January 2018, leaving SWIFT users (roughly any financial institution in the world) only a few months to take action. Organizations that are are found to be non-compliant will be published in a specific directory letting all other users of SWIFT to know that this counterpart maybe not safe to do business with. In practice this means that any respectable financial institution will have to do the effort to comply with the new regulations.

It is interesting to see what brought SWIFT to create this guidance and start enforcing them leaving all its users only several months to prepare themselves (well, 9 months to be exact, but still some of the requirements are not very simple to implement, which creates quite a lot of pressure). While there is no official explanation rather than general rise of cyber threats (“The growing cyber threat requires a concerted, community-wide response” – SWIFT Chairman Yawar Shah), the common understanding is that this action was provoked by a series of targeted attacks on the SWIFT messaging system. One of the most known of them is by a dedicated malware found in Bangladesh Bank where malicious transactions were introduced into SWIFT and concealed there allowing the criminals behind the attack to steal 81 million dollars. And some other similar attacks.

The crucial part is that in none of those attacks was there any fault was found in the SWIFT system itself, but rather the lack of security inside those client banks allowed the criminals to gain access to the critical system. Thus in an attempt to protect its own reputation, and the reputation of the financial services community, SWIFT created a set of requirements on how its system needs to be deployed, segregated, maintained and managed from the security perspective. The mandatory requirements and the expected sanctions against those who will not comply are expected to provide better protection for SWIFT from a client with overall bad security practice.

The Customer Security Controls Framework lists 16 Mandatory and 11 Advisory requirements, the auditing and sanctions will of course address only the mandatory requirements, but customers are welcome to ask for advisory requirements compliance for their SWIFT peers to better assess risks of communicating with the other part by SWIFT.

SWIFT Mandatory Controls – the Basic SWIFT Guidelines

The mandatory requirements fall into 7 logical groups:

  1. Segment your network to restrict access from general IT to SWIFT servers and within the SWIFT related servers
  2. Reduce attack surface by maintaining vulnerability patching and OS hardening
  3. Physically secure the SWIFT environment
  4. Prevent compromise of credentials
  5. Manage identities and privileges
  6. Detect malicious activity inside the environment
  7. Plan for incident response for those activities

Of course those requirements make total sense and are targeting to reduce the risk of attacks on SWIFT system from the general IT of the organization (e.g. non SWIFT related servers, desktops etc.) In fact, some of those can be found in other standards such as PCI/DSS.

But of one of my key observations is that while, logical and justified, some of those requirements are not easy to comply with and will require a lot of effort from the SWIFT clients (in the words of SWIFT chairman: “We recognise that this will be a long-haul, and will require industry-wide effort and investment, as well as active engagement with regulators”).

In my next blog I will look deeper into those requirements and will break down some of them to see what kind of activities and tools are needed to ensure compliance.

So, if you are a SWIFT client, it’s time to take those requirements seriously as not much time left before the auditing will begin and there is some work to do, but the good news is that this effort will probably serve to upgrade your overall security and thus will be more than just pain in the ass.

Detailed requirements as well as implementation guidelines can be found here:


Your Business Is Evolving, Don’t Let Your Security Strategy Be Left Behind

The way businesses and IT teams are executing today has dramatically changed and will only continue to do so.   More and more organizations are embracing DevOps, Infrastructure as a Service (IaaS) and application-centric practices.  The goal of these changes is to enable IT teams to dramatically accelerate and more effectively adapt and respond to their organization’s business needs.

Read more