On September 20th, SWIFT, the global provider of financial messaging, announced the creation of a new security tool to ‘strengthen customer fraud controls’. This tool allows SWIFT customers (banks) to detect unusual payment flows and improve the possibility of cancelling fraudulent transfers.
While IT based bank fraud is not new, this move can be seen as a response to the $81 million heist perpetrated against the Central Bank of Bangladesh last year using the SWIFT network.
New controls reduce the “Fraud Detection Gap”
The new tool functions by performing ‘out of band’ validation of the communications sent using the SWIFT network. This validation is achieved by cross checking the daily Activity and Risk reports that the tool produces against the true activity reported within the bank’s own systems. Essentially the validation is confirmed when the list of reports are checked and reflect the transactions that were processed. This presumes the allocation of a resource dedicated to the validation process and is intended to reduce the period of time wherein a fraud may occur to a manageable 24-hour period of time.
Ultimately, the new tool is geared towards reducing the fraud detection gap, improving the likelihood that a bank can cancel fraudulent transfers.
This approach is to be encouraged:
- SWIFT has found a way to decouple trust in the underlying customer systems where reports and records may have been manipulated; and
- Banks have a responsibility to validate the messages sent over the SWIFT network every 24 hours to ensure that the actual communications synch with the reports (i.e. that what the banks believe has happened is what actually happened).
The default security posture is thus transformed from ‘everything is correct, until we discover an issue’ to ‘fraud has happened, unless we can prove otherwise.’ In effect, the new position is based on inherent suspicion of all activity.
Extending this practice to endpoint security
While this new approach is an excellent first step, it begs the question of why SWIFT’s Internal Customer Security Intelligence team hasn’t extended the scope to include performing a similar validation exercise on the dedicated endpoints that connect to the SWIFT network.
Unless these endpoint machines are verified as malware free, there is no reliability in any reports generated, nor in the transfers that are executed. Malware that infects endpoints generally lays dormant for a period of time prior to execution and once activated there is another variable period of time before the malware is detected. The breach detection gap refers to this period of time between first execution of malware and its discovery.
Machine validation could occur on a daily basis for these critical endpoints, enabling the establishment of reasonable limits controlling the breach detection gap that mirror the fraud detection gap they have created.
An endpoint validation approach would help the SWIFT Network and banks to:
- Remove blind trust in defensive technologies that are not 100% effective; and
- Remove blind trust in endpoints to alert defensive technologies of events; and
- Remove the ability of malware to persist undetected beyond a define and managed period of time; and
- Limit the exposure/damage from malware that is being used to send communications or manipulate underlying systems that smaller banks heavily depend on for accuracy to defined periods of time;
The new default security posture evolves from “these endpoints are trusted because existing defenses report no breach/problem” into “these endpoints can’t be trusted until demonstrated otherwise”. This is a mirror reflection of the new standard SWIFT is establishing regarding the message validation process.
Ultimately, while SWIFT has made progressive steps toward tightening controls and protecting the integrity of the communications over its network, the organization has overlooked a critical element. The physical endpoints that support the network are prime targets for malware, and - with the new approach – the machines are left vulnerable with no verification that offers proof that the endpoints are clean and malware free. Without this step, it can be argued that the message validation protocol can be rendered impotent.
Learn more about endpoint validation solutions.