Running Regulated Workloads in a Public Cloud
By David Weck and Charlie Brown, IBM Distinguished Engineers working in the Cloud Engagement Hub with clients on their journey to cloud.
Nothing can strike fear into a regulator or a financial institution like the thought of running financial regulated workloads in a public cloud. There is both fear of being breached and the resulting impacts that it can cause for your reputation and for your customers, but also the fear of financial penalty for failing to ensure adequate protection. Failure to comply can carry very stiff penalties in the financial space.
It is a little like getting someone to eat their broccoli, as they know it is good for them but they are afraid to try it for the first time. Public clouds provide the most economic and cost-efficient environments but can you trust using it will be a good experience?
Let’s start with shared responsibility and understanding what that means in a public cloud model.
Generically, public cloud providers will make statements like “Clients are provided with full ownership and control” of how they store and protect their data or “You choose how your content is secured”.
If you mis-configure something and expose your data in plain readable format, all the security controls simply become irrelevant. Keeping the data within the four walls of your data center might seem to prevent such exposures, but in reality, access can be configured incorrectly, and everyone has to deal with potential insider threats as well.
While running all your IT in-house can be more comforting, public cloud computing is today, or it will become, the most cost-efficient option for some workloads; and startups, acting as disrupters, are already gravitating there and gaining significant market share and customer acceptance.
When you make the decision to put your workloads in a public cloud, it is very important to adopt several key concepts and to vet your provider on various governance, risk, and compliance policies related to security.
The most important is adopting a practice of “Zero-Trust”. Many definitions exist for Zero-Trust, and through our work in the Cloud Engagement Hub, Charlie and I define Zero-Trust in that you implement measures which trust no one with access to your data without a defined and validated set of controls. The best security practices follow “Trust nobody not even yourself” which many convert into a “Never Trust, Always Verify” set of security policies.
When putting workloads and data on a public cloud, the security model is almost always a joint responsibility between the owner and the service provider. There are clearly things which the service provider and the owner should always follow:
1) Multiple layers of control, meaning that there are at least two failures are needed before you have a breach.
2) Data should always be encrypted in transition and at rest. This is a fundamental element of security hygiene. If someone unauthorized somehow gets your properly encrypted data, it becomes essentially worthless to them without the encryption key.
3) Encryption Key Management must meet the highest security processes available, and no single person should be trusted to manage the keys independently. For customer data, the service provider should not have access to the keys to decrypt the data. The keys are the most important asset since if they are compromised, all data encrypted with that key (past, present, or future) could be compromised.
4) There should never be someone who has privileged or elevated access to the systems or the data without following fundamental security practices. Each person should have to check out credentials, have a documented record of why they are checking out those credentials, and all their actions whether they be operator access or data access, should be logged in such a way they cannot modify the logs. In addition, the person who assigns administrative responsibilities should not be granted admin responsibilities themselves.
5) No changes should be executed outside of a formal change management process which requires someone other than the change execution person to sign off on the change.
6) Data deletion must follow stringent guidelines like NIST standards to ensure the delete data is not recoverable.
7) Operators and Administrators must be trained on working within a financially regulated environment.
8) Regulations vary federally, by individual states, and by different countries. These must be understood and addressed by both the cloud provider and the client, and as regulations change or new ones are adopted, they must be incorporated into the regulated environment.
9) Continual Compliance must be proactive, automated, enacted and enforced across the environment. Long gone are the days of yearly releases of code in which security compliance can be checked right before release. DevOps has changed the process to include up to multiple new releases per day. This means security processes, and validation must shift left in the process and DevOps needs to change to DevSecOps.
It is inevitable that financial regulated workloads will run on public clouds. Many fintech startups are growing quickly, and to scale they will turn to public clouds. The key is to ensure your workloads, data and service provider understand the regulatory environment for your company and your industry, and they can be validated to follow the proper security and operational hygiene needed to host your workloads and data.
There is no need to start from scratch as public cloud providers are collaborating with their customers on developing and implementing specific requirements of financial services institutions for regulatory compliance, security, and resilience in public clouds.
While every client’s regulatory controls may vary, companies like IBM and Bank of America have collaborated on a set of controls that meet the needs of a very large bank, and thus presumably many of these will be applicable to other financial institutions necessary for regulated financial workloads in a public cloud. This collaboration has resulted in IBM announcing the world’s first financial services ready public cloud.
IBM can help vet companies who use the IBM Public Cloud for compliance, security, and privacy, and they will work together with their clients to maintain compliance as regulations change over time.
The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
