COUNTDOWN TO SWIFT SECURITY COMPLIANCE

By David Higgins, Director of Customer Development, EMEA, CyberArk

The SWIFT network should be considered a part of our critical infrastructure. It is fundamental to the flow of money around the world, enabling 11,000+ financial institutions to send and receive information about financial transactions in a secure, standardised and reliable environment.

In recent times, however, users of the SWIFT network have been targeted by cybercriminals. With one successful heist having the potential to open the tap on millions of pounds, attackers are looking for any way in. In the last two years, we’ve seen three publicised breaches of organisations utilising the SWIFT network; the most notorious being the Bangladesh Central Bank where attackers made away with $81 million.

The anatomy of a SWIFT attack

Just like any other advanced cyberattack, the route to the crown jewels (in this case the SWIFT-connected systems) is by exploiting privileged accounts. After breaking through the perimeter, the attackers can start looking for credentials to move to another area of the network. Using stolen privileged credentials, they can then escalate privileges and move laterally through the host environment until they reach the lucrative SWIFT-connected systems.

In the case of the Bangladesh bank heist, this was the stage where the attackers started monitoring what the administrators and users of those systems were doing, so they could start to make requests. They also noticed that each time a transaction was issued, it would be sent to the printer too. Using exploited credentials, the attackers disabled the printer, helping them to remain undetected as they issued false transactional requests.

The SWIFT response

While the SWIFT network has not been compromised, its users have been, so SWIFT has responded with a robust Customer Security Programme. Some elements are advisory and some are mandatory, but, in total, there are 27 controls to be implemented across the community by January 2018. Not all SWIFT customers will need to adhere to all 27 controls. It all depends on the architecture they have; determining this will be the first step to understanding which of these controls they need to follow to get compliant.

Prioritising privilege

Across the 27 controls, whether they are mandatory or advisory, privilege is a common theme. Attackers are looking to perform lateral movement and exploit systems connected to the SWIFT network, and privilege is the path to do that. As the countdown to SWIFT security compliance begins, financial institutions need to recognise the scope of privilege is far broader than simply ‘credential management’ and address it in the following three ways:

• Lock down credentials: First, it’s about identifying privileged accounts within the SWIFT environment and locking down credentials. ‘Credentials’ isn’t just passwords; there can also be credentials used within applications or SSH keys. One of SWIFT’s required controls talks about managing your administrative level credentials, so let’s say you secure the root password on all your unix devices. If your administrators have SSH keys that they’re using to authenticate this route then you’ve not actually achieved compliance – your administrators will simply bypass that control with SSH keys.
• Isolate and control: Once you’ve locked credentials down, you need to isolate and control privileged sessions. By introducing a session broker and monitoring those sessions, you can start to understand what administrators and users of the systems are doing. It’s no longer just a case of managing credentials, rotating passwords and making sure that they’re set to a strong value; it’s also about looking at the admin rights and the entitlements users have to get on the systems. If you’ve got a highly privileged account, for example a domain administrator account that can connect to all the Windows servers within your SWIFT secure zone, the attackers are going to target that account. They know if they compromise that one account they’ve got admin access to the organisation’s entire Windows infrastructure. If you were to give out least privilege (i.e. non-administrative access) to the users, and it’s a non-admin account that’s compromised, it makes the attacker’s journey far more difficult.
• Continual monitoring: Financial institutions need to be able to spot when attackers are trying to exploit credentials and perform behaviour analytics around these users. We know the types of accounts which will be a target for attackers, so putting some detection around their behavior will allow us to spot abnormal patterns when it comes to privileged users.

In this highly secure environment, financial institutions need to make sure they’re giving the right users the right access at the right time. By making sure privileged activity is locked, monitored and trusted, it will not only be far more difficult for attackers to get into the SWIFT environment in the first place, but any insider threats will quickly be detected and stopped in their tracks.

By David Higgins, Director of Customer Development, EMEA, CyberArk

The SWIFT network should be considered a part of our critical infrastructure. It is fundamental to the flow of money around the world, enabling 11,000+ financial institutions to send and receive information about financial transactions in a secure, standardised and reliable environment.

In recent times, however, users of the SWIFT network have been targeted by cybercriminals. With one successful heist having the potential to open the tap on millions of pounds, attackers are looking for any way in. In the last two years, we’ve seen three publicised breaches of organisations utilising the SWIFT network; the most notorious being the Bangladesh Central Bank where attackers made away with $81 million.

The anatomy of a SWIFT attack

Just like any other advanced cyberattack, the route to the crown jewels (in this case the SWIFT-connected systems) is by exploiting privileged accounts. After breaking through the perimeter, the attackers can start looking for credentials to move to another area of the network. Using stolen privileged credentials, they can then escalate privileges and move laterally through the host environment until they reach the lucrative SWIFT-connected systems.

In the case of the Bangladesh bank heist, this was the stage where the attackers started monitoring what the administrators and users of those systems were doing, so they could start to make requests. They also noticed that each time a transaction was issued, it would be sent to the printer too. Using exploited credentials, the attackers disabled the printer, helping them to remain undetected as they issued false transactional requests.

The SWIFT response

While the SWIFT network has not been compromised, its users have been, so SWIFT has responded with a robust Customer Security Programme. Some elements are advisory and some are mandatory, but, in total, there are 27 controls to be implemented across the community by January 2018. Not all SWIFT customers will need to adhere to all 27 controls. It all depends on the architecture they have; determining this will be the first step to understanding which of these controls they need to follow to get compliant.

Prioritising privilege

Across the 27 controls, whether they are mandatory or advisory, privilege is a common theme. Attackers are looking to perform lateral movement and exploit systems connected to the SWIFT network, and privilege is the path to do that. As the countdown to SWIFT security compliance begins, financial institutions need to recognise the scope of privilege is far broader than simply ‘credential management’ and address it in the following three ways:

• Lock down credentials: First, it’s about identifying privileged accounts within the SWIFT environment and locking down credentials. ‘Credentials’ isn’t just passwords; there can also be credentials used within applications or SSH keys. One of SWIFT’s required controls talks about managing your administrative level credentials, so let’s say you secure the root password on all your unix devices. If your administrators have SSH keys that they’re using to authenticate this route then you’ve not actually achieved compliance – your administrators will simply bypass that control with SSH keys.
• Isolate and control: Once you’ve locked credentials down, you need to isolate and control privileged sessions. By introducing a session broker and monitoring those sessions, you can start to understand what administrators and users of the systems are doing. It’s no longer just a case of managing credentials, rotating passwords and making sure that they’re set to a strong value; it’s also about looking at the admin rights and the entitlements users have to get on the systems. If you’ve got a highly privileged account, for example a domain administrator account that can connect to all the Windows servers within your SWIFT secure zone, the attackers are going to target that account. They know if they compromise that one account they’ve got admin access to the organisation’s entire Windows infrastructure. If you were to give out least privilege (i.e. non-administrative access) to the users, and it’s a non-admin account that’s compromised, it makes the attacker’s journey far more difficult.
• Continual monitoring: Financial institutions need to be able to spot when attackers are trying to exploit credentials and perform behaviour analytics around these users. We know the types of accounts which will be a target for attackers, so putting some detection around their behavior will allow us to spot abnormal patterns when it comes to privileged users.

In this highly secure environment, financial institutions need to make sure they’re giving the right users the right access at the right time. By making sure privileged activity is locked, monitored and trusted, it will not only be far more difficult for attackers to get into the SWIFT environment in the first place, but any insider threats will quickly be detected and stopped in their tracks.