Securing the SWIFT environment
Restricting Internet access with Secure Remote Browsing
“Why do you rob banks?”
“Because that’s where the money is”. Slick Willie Sutton, 1952
Some things change, and some things stay the same. Banks are still where the money is, but bank robbers today are less likely to use guns and a facemask like Willie Sutton, and more likely to use a keyboard and an Internet connection.
Recent attacks exploiting the SWIFT network (Bank of Bangladesh, Banco de Austro, Far Eastern International Bank) have led to renewed emphasis on securing the SWIFT environment, and in particular to the need to restrict Internet access from the SWIFT environment.
But restricting Internet access is easy. What is harder is keeping business processes working, because in practice many working patterns require Internet access. There is thus a need to restrict Internet access from the SWIFT environment while still providing Internet access to the SWIFT user.
One option is to use physically separate terminals. Where feasible, this is a very strong security control. But practical issues and the lack of integrated workflow (for example, support for following links and copy-and-paste) can make this a difficult control to deploy.
Is there any other realistic alternative? Are there any other security controls which can provide both separation and access at the same time?
Banking networks already provide extensive security to protect against Internet threats. Perimeter controls such as firewalls and proxies work hard to keep threats away from sensitive systems and data. Standard Operating Systems (e.g. Windows 10) and browsers (e.g. Chrome) already contain extensive security features designed to ensure that any Internet-based threats which are encountered are neutralised and isolated.
The need to restrict Internet access from the SWIFT environment arises because even these extensive security controls may, faced with a motivated attacker, fail to prevent a breach. Clearly the risk is that any other control might face the same fate: overwhelmingly successful the vast majority of the time, but potentially vulnerable to a sufficiently motivated, skilled attacker.
A security control which provides Internet access while meeting the true definition of “restrict Internet access” is precisely what military and national security organisations have wanted for many years. Those organisations have extensive systems whose Internet access must be properly restricted, but system users who need ready access to Internet information.
Those markets have typically relied on physically separate terminals, but have in some cases sought to use a “remote browsing” approach whereby a sacrificial remote machine accesses the Internet, aiming to isolate the user’s sensitive machine from risky Internet content and services.
Over a decade of learnings from this military and national security world have led to the development of extensive best practice that teaches where and how remote browsing can be used. The same guidance is of direct relevance to those considering options for SWIFT.
1. Claiming isolation through remote browsing is not the same as delivering isolation. Many security controls claim to deliver isolation but leave too many side channels and loopholes that allow an attacker to sidestep the supposed isolation. These solutions provide insufficient security
2. Software-based remote browsing solutions are inherently vulnerable. Some countries have taken the view that, as a result, software-based remote browsing solutions should not be used to protect classified systems. Other countries have taken the view that software-based solutions can be used but only in a defence-in-depth model where two different solutions are used in a “double-hop” configuration (ie one remote platform used to access a second remote platform which in turn is used to access the Internet)
3. Remote browsing solutions where isolation is provided at the hardware level can potentially be secure enough to provide users of classified systems with access to the Internet. Even here, great care must be taken to ensure that hardware-based security enforcement does not leave side channels and loopholes.
Hardware-based remote browsing solutions have not historically been available to the commercial market. With Garrison SAVI? that situation has changed.
Garrison SAVI? is a hardware-based remote browsing technology which is undergoing certification by the UK Government’s CAPS scheme for use providing Internet access to users of high-classification systems and networks. But unlike traditional high assurance technologies which attract “government grade” pricing to accompany their “government grade” security, Garrison SAVI? is priced for large-scale enterprise deployment.
Garrison SAVI? can provide Internet access for the SWIFT environment today, but can scale to bank-wide deployment tomorrow, providing unprecedented levels of protection against phishing, watering hole and drive-by attacks.
Alongside its work with Government organisations, Garrison is working today with banks and other financial services organisations, as well as with customers in other sectors including media, telecommunications and professional services.