Recently, the SwissBankingAssociation (SBA) released a whitepaper called “Cloud Guidelines – A guide to secure cloud banking”. The document can be downloaded in German, English and French here – English PDF directly here.
Within this blog posting, I intend to quickly review the whitepaper from a technical security perspective and discuss some the statements provided by the authors. (Disclaimer: Screenshots below have been extracted from the SBA PDF)
Before we dive into the details of the paper, it is important to understand what the core intention of the SBA is. Details can be found on their website here:
“The Swiss Bankers Association (SBA) represents the interests of the banks in Switzerland and advocates for optimal locational conditions.”
The whitepaper outlines in the beginning the benefits and advantages of moving banking data to the cloud (e.g. time to market, cost reduction, more innovation etc.). While these are common arguments, the associated risks should not be underestimated as outlined in section “Regulatory issues related to cloud banking”.
Within the next sections I tried to extract the major statements out of the paper and quickly comment on them from a technical security perspective.
Choosing and changing cloud providers and subcontractors
This requirement is not new and also counts already for traditional outsourcing – however, what is written easily, is highly complex from a technical security perspective. Moving data to a cloud provider makes this provider part of your supply-chain. Supply-chains are an interesting attack surface for adversaries and more and more incidents based on supply-chain attacks got published in the recent past (the attack on Wipro was used to attack other firms, the successful attack on Target was also based on a weak supply chain and we all remember the recent ASUS supply chain attack). So while methodologies for assessment 3rd party related risks exist, it still remains a gambling game. Daniel Miessler has a great and honest article about this situation called “Third-party Questionnaires Are Security Theater” – you can find it here.
Additionally, it will remain questionable whether global acting cloud providers will provide full technical transparency towards their Swiss banking clients in order to let them assess the risks properly.
While this sounds great and like total freedom, reality looks different. Vendor-lock-in also exists in the cloud area and although the industry promises full freedom and flexibility, hundreds of running systems and applications set up with complex VLAN/networks including thousands of ACLs are not migrated overnight to another vendor simply because the current one does not comply with the bank’s requirements anymore. This could mean intensive work for weeks and months. Banks, as all other cloud customers, need to keep in mind that the cloud vendor normally does not have any benefit from offering a setup that is migrated within a short time period to another vendor. Vendors have the interest of keeping you as a client as long as possible.
Again, easily written on paper – hard to execute in practice. As outlined in the paper, one of the benefit of using clouds lies in the cost reduction through scalability, pay-per-use etc. – customers normally do not maintain a local exit plan for going to the cloud since this reduces the benefits of the cloud move substantially (additional costs through local operations, hardware etc.). Once you move to the cloud, you create yourself a dependency that you cannot get rid of easily.
Maintaining banking secrecy in the cloud
The guideline clearly states:
So this could be the end of this journey already. However, the black magic here lies in the words “by means of technical, organisational and contractual measures”. These measures are now quickly listed and described as in the paper on page 13 and 14.
This requirement is not primarily driven by the cloud situation – it already exists for some while for production data that should be moved to a testing or developing environment. Due to the reduced security controls in place in most of these environments, data should get anonymized / pseudonymized beforehand. In my opinion this is already a challenge for a lot of companies without even talking about the cloud.
However, the situation will be heavily depending on the specific scenario the bank intends to implement. I assume that banks have anonymization/pseudonymization procedures already in place for their dev/testing environment – if this is the case, applying it to a cloud scenario should be possible.
Finally, we need to be aware that applying anonymization and/or pseudonymization measures to the production data before pushing it to the cloud could take away a core benefit of the cloudification. The real benefits of clouds can only be leveraged if production data can be used – without sanitizing the data somehow beforehand.
Encryption is probably one of the most-widely misunderstood security controls when it comes to cloudifying IT operations.
Let’s start with the last sentence which focuses on “encryption of data in transit”. Nowadays this is a no-brainer – the usage of SSL/TLS is widely spread and should be supported by most of the modern applications and systems. Just ensure that you use the latest version and that your setup is not vulnerable to downgrade attacks. Important in the context of encryption of data in transit is also the aspect of where the TLS tunnel terminates. The idea is normally to use TLS as an end-2-end encryption mechanism – however, especially in the banking context, network components in the middle might terminate the connection for DLP / IDS & IPS purposes. On the banking side, banks can control this on their own – on the cloud provider side, it depends on the architecture of the cloud provider.
Encryption of the data at rest is way more complicated in case we do talk about data processing (not simply storage). Encryption of data that simply needs to be stored is relatively simple: The key only remains on the banking side where encryption and decryption is done – only ciphertexts leave the environment and there is no processing need on the provider side. However, again, this is not what banks want – in order to leverage the full set of benefits, data in the cloud needs to be processed by cloud-based applications. Today, 2019, this still needs to happen in plaintext in most of the cases – this means, the banking data is visible in plaintext to the machines of the cloud service provider. This represents an immediate issue with the banking secrecy requirements mentioned above.
The holy grail that academia is hunting is called “fully homomorphic encryption” originally invented in the late 1970s by Rivest, Adleman and Dertouzos in the paper “On Data Banks and Privacy Homomorphisms”. Interestingly, the example used by the authors in the paper pretty much relates to the some of the data modern banks nowadays store and process. In 2009, Craig Gentry further progressed this topic in his PhD thesis. The value-add of homomorphic encryption lies in the data processing of encrypted data – this means, data is not needed to be available in plaintext beforehand. Only the ciphertext is needed and mathematical operations are directly applied to the ciphertext without revealing the plaintext. The decryption later reflects that operation as well.
Obviously, this is what we need for cloud operations – however, the problem is that there aren’t any widely applied standards available that are efficiently implemented in major applications. Furthermore, this is a highly technical & mathematical problem that requires highly skilled people which goes way beyond what “normal” infosec people are able to do. Finally, the performance penalties are high although research is slightly progressing.
The unfortunate conclusion is: In 95% of the cases, the cloud service provider will need full plaintext access to your data in case you want him to process (not only store) your data.
This is caused by the fact that fully homomorphic encryption is most probably not available for most of the banking application scenarios – hence, it will require the data to be processed in plaintext, hence visible to the cloud service provider and to all potential adversaries (external, malicious insiders such as admins, employees etc.). The statement in regards to the key by the SBA above is therefore not feasible: “access to the key should be controlled by the bank”.
Instead, the subsequent statement applies: “the key may be made available to or held by the provider” – yes, this is needed and represents an issue considering the banking secrecy requirements. Both statements made by the SBA are highly contradicting.
These measures refer primarily to topics like ISAE based assurance reports, ISO 27001 attestations etc. which I consider already to be standard requirements for outsourcing intentions nowadays. Auditing cloud providers is still an interesting topic since cloud providers will never give the full insights into their environments.
The “contractual measures” are known ones as well from the traditional outsourcing area – none of them I would call cloud-specific.
Transparency and collaboration between institutions and cloud providers with regard to measures ordered by the authorities and the courts
Technically, there is no possibility to actually enforce this procedure. The client fully depends on the cloud provider’s willingness to inform the client based on the contractual situation.
Audit of the cloud services and means used
With the topic of auditing cloud environments from a technical perspective, you could fill books with. It is a complicated topic that requires a huge amount of willingness and transparency from the cloud provider’s side. I agree that banks should collaborate with each other in order to audit market-leading cloud providers together in order to become more efficient.
I fully understand the intention of Swiss banks to move to the cloud. However, it needs to be clearly assessed what kind of written statements / requirements can be executed in what kind of technical way in a real-world scenario. A guidance is nice to have for such purpose – but what counts is the risk-reducing control that gets implemented in order to comply with customer / legal requirements.