Today, financial institutions are driven by a strategic question: How can they embrace the benefits from the cloud’s flexible and scalable on-demand services, while perpetuating a trustworthy, banking-grade level of cryptographic security? This article looks at some of the trends, challenges and security concerns that financial institutions face when considering whether to migrate their business-critical applications and cryptography to the cloud.
For clarity, the scenarios and applications described here relate to high-security cryptography, which typically requires hardware security modules (HSMs) for the secure generation, protection and usage of cryptographic keys.
Over the past few years, an increasing number of banks and financial institutions have implemented private cloud architectures to manage a decentralized and heterogeneous landscape of locations and applications. Some of these data centers are on-premise or in an owned, but geographically separate location.
Banks and financial institutions are increasingly feeling the pressure to migrate IT services from on-premise, self-managed data-centers to public cloud services. With the promise of lower costs to improve bottom lines, there are definitely significant advantages to embracing the native elasticity and resilience that cloud computing can bring to the banking and financial sector. These advantages align well with modern goals for rapid and agile development and delivery of products and services, to differentiate banks and others from their competition.
However, for many business-critical financial applications, security concerns are the largest barrier-to-adoption for cloud computing. The aggregation of sensitive data, critical business processes, and other corporate IP on a publicly-accessible platform creates risks that require considerable mitigation efforts.
At the C-level domain, these tensions can be portrayed as Finance and Commercial domains seeking efficiency and business agility versus Risk and Compliance officers wanting to manage possible liabilities. There can be opposing factions even within the IT domain. Recent computer-science graduates who are ‘Cloud Natives’ who view elastic services as the norm are pitted against seasoned IT security practitioners with set notions as to what they consider ‘good security practices’ to be.
This is a common paradox that many enterprises and financial institutions are wrestling with: Whether to move forward with adopting cloud computing for efficiency and innovations versus caution roadblocks placed by corporate responsibility to protect sensitive data and processes.
There are multiple barriers to safely and efficiently run business-critical cryptography in the Cloud.
Data Security and Privacy
With the decision of placing sensitive data in the Cloud, the data security and privacy assurances depend, to a certain extent, on the hosting company. The software and hardware infrastructure (IT architecture), the level of physical protection of the IT architecture and its perimeters (physical infrastructure), as well as the personnel involved and their security-related processes (procedures) are all critical considerations.
In a hosted environment that is out of the banks’ control, data may be exposed to personnel at the hosting provider or to third parties (without the bank’s knowledge).
The cloud service provider could handle the protection of data and communication. However, this could lead to a sticky lock-in situation if the cloud infrastructure provider owns the data encryption keys. Any future switching of providers could be difficult and potentially lead to data loss or tedious migration procedures.
When using multi-cloud environments for storage or even for applications, the end-to-end journey of data might pass through various hosted environments. This brings about the dilemma of key ownership. This challenge grows even more complicated when adding SaaS provided by different service providers on one or more cloud service platforms to the mix.
Auditability and Compliance
A major challenge for the strongly regulated finance and banking sector is its high level of regulation. Within annual audits, banks need to provide proof of compliance to security standards (e.g. PCI DSS). It can be tedious or impossible for the audited organisation to demonstrate compliance when the cryptography and keys are out of their control.
Cryptography Considerations for Secure Operations in the Cloud
Cryptography is the security foundation for any significant application - to protect data and communication and to authenticate processes and people. For many banking applications, however, their core value is actually delivered through cryptography:
- Banking and financial transactions are ultimately composed of cryptographic functions
- Ownership of a set of keys completely defines a bank’s online existence
Most organisations thus strongly rely on cryptography. However, banks and financial institutions have a specific interest in high-assurance crypto processes, as any compromise can lead to fraud that can directly divert funds into attackers’ accounts. Banks and FIs are correct in being concerned about potentially exposing themselves to increased vulnerability and risk by adopting public cloud services.
Existing On-Prem Services
The cryptography used by existing on-premise applications may be performed by legacy systems and processes that are not clearly documented. The staff who implemented these legacy systems may no longer be a part of the organization. It’s common to adopt an attitude of ‘if it ain’t broke, don’t fix it’ because of concerns that the cost and risk of disrupting such services could outweigh the benefits of moving forward. However, a cloud migration initiative requires clear thinking about all applications, including legacy applications.
There are only three outcomes to consider:
- Retain existing systems on-premises
- Migrate applications to the Cloud
- Move dependent users/services to new functionally-equivalent applications in the Cloud
When any part of ICT goes ‘out of house’, there are naturally concerns about security. In any complex ICT operation involving multiple entities, countries and standards, there are increased security risks.There may also be regulatory problems, such as different legal protections in different countries or regions. And of course, there are usually a series of technical concerns. These issues tend to arise from the aspects of multi-tenancy, international data and code distribution, and associated human resource issues.
Some of these security concerns relate to:
- International and national compliance: The architecture needs to be compliant with international finance standards, such as
PCI DSS, FIPS 140-2 and-3, Common Criteria, and other national regulations that might apply. Some national regulations might also restrict user data to leave the area of jurisdiction.
- Interoperability: Such as common standards for service level and security.
- Security policy management and crypto-agility: Because policies change with perceived threats, and since the cloud environment is so dynamic, policies will need to also be dynamic.
- Early detection: Faults and attacks to secure services, data, and resources should be detectable at an early stage.
- Isolation of workloads: High security might require isolation and execution at specific locations with appropriate security policies.
- Replication of data and computation environments: Instances where data might require replication for security reasons or for increased performance at distributed locations - the right compromise between consistency, availability, partition tolerance (CAP Theorem) and data security needs to be found.
In terms of cryptography and key management, maintaining control over cryptographic data protection is critical; especially in regards to the cryptographic keys of applications. The main reasons for this are:
- Cloud service providers may be changed multiple times and owning encryption keys prevents the effects of being locked-in, potential data loss, or extensive (and costly) data migrations.
- Cloud service providers are third parties who may not necessarily comply with the same regulatory security standards that are required for banks and financial institutions. They should never have access to unencrypted data.
- Data needs to be protected in an end-to-end manner. This means the bank should be able to encrypt and decrypt the data throughout the complete data-life-cycle
There are many architectures and concepts to retain control over cryptographic keys. Bring-Your-Own-Key (BYOK) and Manage-Your-Own-Key (MYOK) are important examples that we will dive deeper into in future articles. However, there are also other important aspects that require case-to-case decisions, such as:
- Shall the Key Management System (KMS) be located on-premise or in the Cloud? In other words, where shall the system(s) that controls and manages the lifecycle and distribution of the keys be physically located?
- Shall the Hardware Security Modules (HSMs) that provide physical and logical protection of the keys and allow applications to securely use the keys be located on-premise or in the Cloud?
- Will the KMS and HSM be located at the same physical location?
- Shall the KMS be hosted on individual physical servers or in multi-tenancy environments?
- How will crypto-agility be accomplished?
- How will audits be conducted?
- What restrictions will the regulations, standards, and compliance requirements impose?
Clearly, there are some major architectural, economic and policy decision that need to be made here. Only a very few vendors are flexible enough to provide solutions no matter what those decisions are.
Cryptomathic's high-grade key management & cryptography solutions have been built anticipating the migration to the cloud so you will find we are able to architect the right solution...
References and Further Reading
- Selected articles on Key Management in the Cloud (2017-today) by Matt Landrock, Rob Stubbs, Stefan Hansen, Joe Lintzen and more
- Key Management in a Multi-Cloud Environment - A blessing or a curse? (2017), by Johannes “Jo” Lintzen
- Moving to the Cloud - Key Considerations (2016), by KPMG
- A CIO's guide to cloud computing investments (2019), by TechTarget
- Buyer’s Guide to Choosing a Crypto Key Management System - Part 1: What is a key management system (2018), by Rob Stubbs
NIST SP800-57 Part 1 Revision 4: A Recommendation for Key Management (2016) by Elaine Barker
Selected articles on Key Management (2012-today) by Ashiq JA, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Peter Landrock, Peter Smirnoff, Rob Stubbs, Stefan Hansen and more
CKMS Product Sheet (2016), by Cryptomathic
White Paper – Deploying CKMS Within a Business (2017), by Cryptomathic
Case Study – Swedbank (2017), by Cryptomathic