SWIFT is a global member-owned cooperative and the world’s leading provider of secure financial messaging services. SWIFT’s messaging services are used and trusted by more than 11,000 financial institutions in more than 200 countries.
With recent hacking involving SWIFT infrastructure, millions dollar could be “transported” to cross boundaries and even in continents. The financial impact will be un-imaginable; SWIFT itself, usually deployed as its own island within the financial institution network but still hackers manage to gain access to SWIFT via impersonation.
Naturally Financial Institution wants to increase the security accessing SWIFT application and one of the requirements is to implement MFA (Multi-Factor Authentication). This is unusual applications that requires authentication that is meant for external customers such as Retail or Corporate Internet Banking.
The case below is one of the exceptions:
SecureMetric had been requested by Bank A to propose a solution for SWIFT to increase the security authentication for its own personnel via Multi-Factor Authentication.
With the limited knowledge of SWIFT Alliance Access (SAA) application, we need to look in-depth to the software for any supported interfaces. The best solution provided needs to observe the following factors:
- Should reduce the system down time
- Minimize the development work or modifying the software source code (in this scenario, any development is out of question)
- Minimize impact to user experience,
- Reduce integration time
With the assistance from Bank A, we notice that SWIFT application does support Radius Protocol by default and so does Secure Metric’s product and SecureOTP. One-time Passwords? Words that sounds familiar to us. Let’s differentiate the meaning of One-Time Password and RADIUS.
One-time passwords (OTP) is a password that is only valid for only one login session, certain time or transaction, which may assist by OTP tokens. OTP tokens can display some length of digits and always change with some criteria such as time, click event etc. Every OTP has different seed code and that’s the reason every OTP token will generate different OTP even the tokens that is manufactured by same factory.
Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized Authentication management for users who connect and use a network service. All the data communication is encrypted by shared key that was agreed by RADIUS server and client.
With support of OTP and RADIUS, we proposed a solution that uses our SecureOTP Authentication Server with OTP token to integrate with SAA. SecureOTP Authentication Server provides authentication service to the client. No code changes or any file changes to the SAA software, but only configuration changes from administrator console.
Technically, the SAA will be configured to forward authentication via RADIUS to SecureOTP Authentication Server. SecureOTP Authentication Server will perform authentication and return authentication result back to SAA. SAA will digest the result and will allow or reject SAA user login based on the result.
The integration was seamless, UAT was flawless and implementation was smooth. Each SWIFT user was presented with an OTP token and they would use it whenever they need to login into SAA.
Bank A then decided to integration the other payment gateway with SecureOTP for MFA. The payment gateway vendor was able to integrate with SecureOTP using web services (SOAP). SecureOTP then has become Bank A’s internal enterprise authentication platform for payment gateway related application.
This is a tale of how a simple request to implement MFA for an internal payment gateway application has grown into an enterprise wide internal authentication platform for payment related gateway system. We encourage you to talk to us today and who knows, there might be another tale to tell.
Disclaimer: SecureMAG Volume 9, 2017
