Skip to content

SWIFT Web access

Introduction

The Society for Worldwide Interbank Financial Telecommunication (SWIFT) provides a network that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment. SWIFT is used in more than 11000 customers in more than 200 countries worldwide.

SWIFT faced several cyber attacks in the past. Attackers found methods to capture sensitive data of SWIFT users. Combined with existing cyber attacks this led to hundreds of millions stolen funds [1] . Securing such a mission critical part of infrastructure as SWIFT is undoubtedly of utmost importance. Therefore, SWIFT has established security policy standards for its customers by increasing the security requirements for logging, as well as managing privileged accounts to the SWIFT infrastructure.

The solution to above mentioned problems is the implementation of Excalibur PAM (Privileged Access Management). Excalibur PAM provides web-based zero-trust access to enterprise resources. Zero-trust means that the client machine doesn’t need to be trusted as nothing is installed on it and all access from it goes via browser. Excalibur PAM protects company infrastructure by managing users and their access to mission critical systems and applications. Every action taken by the user is cryptographically signed to certify it was performed by that particular authenticated user. The effect of this is that there is continuous matching of every user action (as every user action and user PAM session is recorded and cryptographically signed) to strongly multi-factor authenticated identity. With no way to delegate access or claim it was some other user.

Excalibur

Excalibur utilizes the user’s smartphone to act as a secure hardware token for any and all authentication and authorization needs. The ultimate goal is to move all forms of authentication and authorization away from passwords, replace them seamlessly with smartphone-based strong but user friendly multi-factor authentication. Excalibur's unique value is in providing backward compatibility with all the applications, Operating Systems (OS) and services used today thus creating a bridge between the password-based present and password-free future.

Excalibur PAM

Excalibur PAM is able to provide controlled access to most services (servers) applications by supporting a wide range of protocols. All these applications can be accessed by any web browser supporting HTML5, even mobile web browsers are supported. SSH, VNC and RDP protocols support is achieved using Excalibur heavily customized Apache Guacamole[2]. Web resource access is provided by either HTTP-Proxy or Virtual Browser (VB).

Access to PAM protected resources (such as HTTP-Proxy or Virtual Browser protected resources) is granted only on a whitelisted basis and only to strongly multi-factor authenticated users. Excalibur is installed to the existing customer architecture, typically in the secure zone as shown on figures in this document, but it can also be installed in a separate network segment, when network access to every protected resource is allowed.

Excalibur Virtual Browser

Virtual Browser is Excalibur’s implementation of Remote Browser Isolation (RBI). It works by streaming vector images from a server-based instance of Chromium while allowing full remote control of this browser instance by the user directly from his web browser. This is beneficial mainly for security reasons, since the client's browser does not have access to the original HTML page, nor Javascript or cookies etc. DOM is executed in the Virtual Browser, so a web page is completely isolated from the client's browser, thus the name - Virtual Browser. In contrast to video codecs - Virtual browser works with vector graphics and only the modified parts of the image are transferred. This means that the image / text quality presented to the end user is always lossless, no matter the resolution, frame-rate or other factors. As with all Excalibur PAM components - Virtual Browser records all sessions. User input is indexed and saved, so it can be used for pattern matching, or other analytics purposes.

Excalibur HTTP-Proxy

HTTP-Proxy is a light-weight alternative to Virtual Browser. It serves a similar purpose as Virtual Browser, but does not share the same security advantages such as complete DOM isolation, yet it has its own benefits - mostly compatibility wise. It terminates HTTP(S) connection from the client and creates a new one to the server, effectively acting as a Man-in-the-Middle. Main difference between HTTP-Proxy and Virtual Browser is where HTML DOM is executed / interpreted. Virtual Browser executes all code on the server side, which has its security benefits and compatibility limitations. On the other hand HTTP-Proxy just proxies traffic, so the code is executed in the client’s browser.

HTTP-Proxy injects a special script to the web page, which records user activity. It can be thought of as a lightweight virtual browser. Recordings are captured directly in the user’s browser and sent to the HTTP-Proxy through websocket. The biggest advantage of HTTP-Proxy is that because DOM is executed on the client browser - compatibility with legacy SW/HW solutions that need to interact with the webpage is preserved - such as USB security tokens, or other HSM solutions etc.

Summary

  • Clients can not access the protected resource directly, only via Excalibur after being strongly multi-factor authenticated. All access is recorded.
  • SAML authentication is integrated directly into the HTTP-Proxy / Virtual Browser.
  • Access to Excalibur can be further restricted by requiring a VPN that would configure the default gateway in a way that would route all traffic thru the VPN to the effect that only Excalibur would be accessible from the PC when the VPN would be connected - thus the PC would not have Internet connectivity when connected to the VPN - effectively defeating a wide range of potential attacks where the PC could be compromised and remotely controlled by an malicious third party.

HTTP-Proxy

  • Client-side recording.
  • DOM is executed directly on the client.
  • HTTP / HTTPS is proxied via Excalibur.
  • Excalibur smartphone based multi-factor authentication (MFA) can be combined with other authentication mechanisms such as USB authentication tokens.
  • Benefit of HTTP-Proxy approach over Virtual Browser is that existing PKI-based authentication mechanisms continue to function while providing the same “business value” - recording of all user activity, no direct connectivity, connectivity only after being strongly multi-factor authenticated.

Virtual Browser (VB)

  • DOM is executed on the VB and just diff-ed & compressed vector images are sent to the user browser.
  • Target website is represented as vector images - thus fully lossless.
  • Server-side recording.
  • USB token authentication solutions can’t be used, because DOM is completely isolated - aka not running on the computer where the USB token is plugged in.
  • Excalibur is used for smartphone based MFA (on-device biometry, location etc.)
  • Benefit of VB over HTTP-Proxy is that the user can not attack the protected web resource as all access to it is just “streamed” to the user, also the user is protected from any malicious activity from the web resource as DOM is isolated on the server. For the purposes of SWIFT these properties are not important.

SAML authentication in Excalibur PAM

Virtual Browser and HTTP-Proxy are both capable of authenticating user via the SAML protocol. Excalibur acts as identity provider (IDP), so authentication can be unified across all service providers (SP) providing a secure and seamless Excalibur authentication experience. Virtual Browser provides total isolation, so SAML messages are never sent to the user’s browser. SAML redirects users from the service provider URL to the identity provider (Excalibur) site, which in HTTP-Proxy context means that for the time of authentication the user is not connected through HTTP-Proxy. After successful authentication the user is redirected back to the same HTTP-Proxy session. More details are in the next figure and description:

  1. User requests target resource.
  2. SAML Service Provider (SP) responds with a redirect message, with SAMLRequest, to the Excalibur SSO URL. This means that the user is no longer in the HTTP-Proxy session.
  3. QR Code is presented to the user.
  4. User scans QR Code using  Excalibur application.
  5. Application asks the user to authenticate using biometrics, while other factors (location, IP address, …) are evaluated in the background.
  6. When authentication factors are successfully checked within security policy configuration, Excalibur Application sends information to the Excalibur Server.
  7. Excalibur Server (IDP) redirects user back to the same HTTP-Proxy session. This message also contains SAMLResponse, which will be proxied to the service provider.
  8. SP responds with the requested resource.

Additional Excalibur Materials


Note 1

[1]

Note 2

[2] https://guacamole.apache.org/