This post is the third part of an eight-part series helping business leaders seeking assurance that their teams have correctly complied with the new controls regime.
In this post we are looking at the second principle: Reduce Attack Surface and Vulnerabilities.
This applies to those with on-premise SWIFT implementations and those using a bureau service. It is intended to minimise your exposure to vulnerabilities that an attacker will have known about and to prevent attackers using default settings to gain access to your systems.
What’s the risk?
Your payments infrastructure naturally has, and indeed needs, the ability to initiate transactions. This makes it a target for criminals looking to steal money from you and your customers’ accounts.
Sticking with the bank vault analogy from our previous post — when installing a vault you would ensure that the materials used are suitably hardened to protect the vault’s contents (such as reinforced concrete and steel!). If cracks appeared through subsidence you would make sure they were checked out and patched up. You’d also make sure the combination on the vault door wasn’t set to the default of 1234!
Where cyber attacks have been successful, attackers have easily been able to use known vulnerabilities and default passwords to access Operator PCs.
The control objective:
The objective of the mandatory controls in this principle is to ensure that hardware and software receive updates from their vendors, closing off opportunities for an attacker to use known vulnerabilities or default settings to compromise your systems.
The controls in this principle are designed to ensure you follow a process to maintain your technology. In doing so, you will reduce the likelihood of these attacks from being successful by making it harder to for attackers to use known vulnerabilities and settings to compromise Operator PCs and your SWIFT infrastructure.
Questions to ask:
When seeking to assure that they have met the obligations of this control, Senior Managers should consider the following questions to give confidence in their attestation and reduction in risk:
Do we have active support arrangements in place for all hardware and software in our SWIFT ‘secure zone’?
All hardware (e.g. network devices, servers) and software (e.g. operating systems, applications) within your SWIFT secure zone should be within the support lifecycle of their vendor. This is so you will receive security updates which reduce the ability of attackers to use known vulnerabilities to compromise your payments system.
In what timeframes are ‘critical’ and ‘high’ security patches applied to systems?
Many organisations apply a risk-based approach to patch management; considering vendor criticality, the operational impact to your business and other compensating controls you may have in place. This will typically by defined within your organisation’s ‘patching policy’. As a guide, the timescales taken to apply security updates rated ‘critical’ (CVSS — Common Vulnerability Scoring System –score of 9.0+) should not exceed 1 month. ‘High’ (CVSS score 7.0+) should not exceed 2 months.
How have we hardened the operating system of Operator PCs?
How have we hardened SWIFT-related applications?
How have we hardened the supporting infrastructure? (E.g. firewalls, routers, etc)
When answering these questions your team should be able to confirm that they have followed industry-standard guidance. They may mention CIS, NIST or local regulator requirements. At a minimum they should be able to confirm to you that default passwords have been changed on all devices, unused system and user accounts have been disabled and that unnecessary software/services have also been disabled or removed.
The following only apply to ‘Architecture A’ (on premise) SWIFT deployments:
How do we encrypt traffic between SWIFT-related applications on our network?
Machine-to-machine interfaces should be secured using encryption like TLS. The encryption should be ‘two-way’ meaning that both applications verify the identity of each other, as well as encrypting traffic between them.
How do we encrypt traffic from our operator PCs to our SWIFT applications?
Connections from operator PCs used to for example initiate transactions, should also be encrypted using TLS. Typically this will be ‘one-way’ meaning only the server’s identity is validated. In the case of a web application users would see the padlock in the address bar.
In conclusion
Typically to have successfully implemented the controls in this principle your teams will have identified the hardware and software used to deliver your SWIFT payment services.
IT teams will have a strong patch management procedure to identify, assess and deploy updates from vendors in a timely manner.
They will also have reviewed the way that hardware and software in your SWIFT secure zone has been hardened against attack in a consistent way.
In doing so your team will have made it more difficult for attackers to exploit known vulnerabilities and use default passwords. This will reduce the likelihood of attackers successfully compromising your SWIFT gateway and operator PCs.
In the next blog post in this series we will be looking at physically securing your environments.
You can also see the rest of the posts in this series.
Remember to follow and connect so you are notified and, in the meantime, please feel free to comment if you have any questions or drop me a message for more information.
