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:
- Segment your network to restrict access from general IT to SWIFT servers and within the SWIFT related servers
- Reduce attack surface by maintaining vulnerability patching and OS hardening
- Physically secure the SWIFT environment
- Prevent compromise of credentials
- Manage identities and privileges
- Detect malicious activity inside the environment
- 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 recognize that this will be a long-haul, and will require industry-wide effort and investment, as well as active engagement with regulators”).
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.
