You can be secure but not compliant, and you can be compliant but not secure. The challenge for FSI businesses is to be both secure and compliant, while also maintaining agility.
Building and deploying applications for the cloud at speed is a challenge for businesses across all sectors, but perhaps more so for Financial Services Industry (FSI) organizations due to the stringent regulations that they are subject to. One of the key conundrums when developing for the cloud is whether to design for one particular Cloud Service Provider (CSP), such as AWS*, Azure* or Google*, or keep applications platform-agnostic.
"The problem with designing an application to be agnostic is that you cannot take advantage of any of the features that differentiate CSPs from their rivals," said Bruno Domingues, Principal Solutions Architect, Financial Services Industry, Intel. “If you design specifically for one CSP, this will enable you to be more efficient by making full use of these specific features. However, the downside is that you must accept some level of lock-in or be aware of the time and costs involved in case you need to move to another CSP".
For financial institutions, the general trend is that they would prefer their applications to be optimised to run their daily workloads, rather than being optimal for one particular event in the life of an application, which may not even happen. Many FSI businesses may be required, either by their own organization or by regulators, to have a Plan B to move from one CSP to another in case of a change in circumstances such as the way a CSP stores its data. This is why many financial institutions are starting to adopt a migration risk approach.
Due to the nature of the workload, whether it's regulated on non-regulated, along with the CSP features that are being used, businesses can define the risk of the time and cost against the risk of the need to migrate. For example, if a CSP uses an SQL interface to access the data, the risk is much lower compared to adopting a Function-as-a-Service (FaaS) approach. This is because a FaaS would use proprietary syntaxes and would likely be costly to migrate.
Another major challenge for FSI businesses creating applications for the cloud is how to create a unified CI/CD (Continuous Integration/Continuous Deployment) pipeline. Containers are rapidly becoming a standard element of the CI/CD pipeline for cloud computing as they enable businesses to deploy an application on any CSP. Containers enable all of the requirements and elements of each application to be moved as a package. However, many FSI applications tend to need high throughput while some demand low latency. Intel is developing a collection of extensions to Kubernetes* aimed at removing these limitations. This will help to create a unified CI/CD pipeline for any application, not only web-based applications.
"The developers and the operations teams are on different ends of the application development pipeline. Having Infrastructure-as-Code enables the integration of these two ends using a common language," said Domingues. "The Ops team build the infrastructure and the Dev team can provision the resources that they need for the application to run and deliver the required service. "However, this means that the security team is left out of the cycle. That's why many financial institutions have already adopted a DevSecOps approach."
The DevSecOps approach, which is still an evolving discipline, involves the security team automating most of the security configurations or best practices in the pipeline. Although humans are still needed in the process, around 80-90 percent of procedures can be automated to speed up deployment. This approach is now used in many organizations across a range of sectors.
However, FSI businesses have a unique challenge. While security best practices are universal, the regulations and compliance that financial institutions must adhere to are often local. "Organizations need to be able to prove that they're adopting all of the elements that compliance requires them to follow, which can vary between countries and territories," said Domingues. "You can be secure but not compliant, and you can be compliant but not secure. The challenge for FSI businesses is to be both secure and compliant, while also maintaining agility."
The challenge of creating a regulatory framework that allows an application to be automatically compliant based on where it is deployed means that more organizations are now looking at the DevSec Compliance Ops approach. This involves the compliance teams creating scripts that enable them to check on how the application has been deployed. Developers are now beginning to use multiple automation tools that translate the security and compliance requirements for the application.
Most data processing regulations are focused on how to handle and store the data. FSI businesses can raise security standards with hardware assistance without losing performance. And in cost terms, this is far more economical than the costs involved with leaked data or fees imposed by regulators for non-compliance. Adopting full-disk encryption is an easy way of rebalancing the risks associated with handling the physical disk.
Not only must the data be protected when it is at rest and in transit, it must also be secured when in use. Confidential Computing focuses on the latter and is set to be a major trend. To support Confidential Computing, Intel provides the foundational technology that enables FSI businesses to keep their data safe. For example, Intel® Software Guard Extensions (Intel® SGX), offers hardware-based memory encryption that isolates specific application code and data in memory. This enables businesses to protect the section of the memory that's executing the code.
By creating one unified pipeline, FSI businesses can develop applications for the cloud at speed, while also ensuring that they're both secure and compliant. This is a major industry trend sure to make a real impact in the months and years to come. Just as in the past regulators have defined best practices on how to handle data at-rest and in-transit using encryption keys, next in line is sure to be data in-use.
For more information: