A common pattern I see in heavily regulated industries is that the Risk and Compliance teams are dictating technology decisions. This ranges from determining which cloud provider (if any) can be chosen to what tools and processes must be used. This can pose challenges because technology decisions should be made by considering all stakeholders, not just those concerned with risk management and audits.
Part of any good cloud strategy is identifying roles and responsibilities. The primary role and responsibility of the Risk and Compliance teams should be to define policy, not to dictate technology solutions in support of those policies. The technology teams should be tasked with architecting solutions that comply with these policies.
Here are some common challenges that companies often face in the areas of Risk and Compliance:
Mistaking current implementations and processes as requirements
Policy definitions are requirements. Current state implementations of those policies are not. Too often I see “Requirements” dictating what process or what vendor solutions must be in place in the cloud. An example of this is network segmentation. I have seen “requirement” documents that spell our exactly how network segmentation must be implemented in the cloud. This is incorrect and detrimental to the architecture in the cloud.
The public cloud service providers (CSP) have abstracted the underlying network infrastructure and provide APIs to allow you configure network segmentation in a much more efficient and effective manner than how we solved things in the datacenter. The VPC (virtual private cloud) provides flexibility for architects to meet policy requirements in support of security, risk, and compliance requirements. Leverage the cloud leading practices for network segmentation and let go of the data center way of doing things.
Applying data center auditing leading practices to the cloud providers
CSPs do not allow access to physical machines in their data centers, so you should not ask them to bring your auditors in for a site visit. If you are Bank 1, do you want Bank 2’s auditors walking the floors of your datacenter? The cloud providers must protect against that as well. Some cloud providers will allow you to tour their facility but all you will get is a distant view of machines with blinking lights and you won’t have any idea which machines actually host your data. So basically, a tour of a CSP is not time well spent, yet some companies still do it to check the box for their auditors.
Some companies want to audit the CSPs IT processes. They insist that the certifications the CSPs have only are representative of a point in time and do not ensure that the proper processes are being followed daily. Once again, you are not going to be able to walk the floors at your favorite CSP to audit their IT processes. CSPs deploy multiple times daily. They get audited more than once a year. Do we need real time certification? This request is just not feasible. Some CSPs deploy hundreds of times a day. At some point you have to accept that their certifications are sufficient and accept some level of potential risk that there may be instances where the CSP is not in compliance.
Not adhering to the shared responsibility model
CSPs have a well-defined shared responsibility model (see picture example figure below).
In this example model, customers are responsible for everything above the hypervisor and the CSP is responsible for everything below the hypervisor. But too often companies burn a lot of energy trying to audit CSPs people, process, and technologies that are not in the customer’s scope of responsibility. If customers can’t adhere to the shared responsibility model of the cloud, then they should not use the cloud. But if they want to use the cloud effectively, they should avoid spending time and energy trying to look at things below the hypervisor.
I remember being at a presentation where a CSP was explaining how their cloud platform performs live migrations with zero downtime. There were a few security engineers in the audience who were asking how they could get all of the log files from CSP’s datacenters to prove that the live migration process was compliant. Just stop it! What CSPs do under the covers is their secret sauce and is their responsibility, not their customers. Just because you have access to infrastructure logs on-premises does not mean you need to have them in the cloud. Adhere to the shared responsibility model and stop spending cycles on anything that falls below the hypervisor.
Risk and Compliance teams play an important role in the adoption of cloud, but they shouldn’t be dictating technology and process decisions. They should be determining policies and requirements and review how the architecture and design addresses those requirements. How risks are addressed in the physical datacenter are very different than how risks are addressed in the cloud. Understand and apply the shared responsibility model. If you can’t accept the shared responsibility model than cloud may not be the right choice. However, the company that does not adopt cloud could be at a real disadvantage if they are still in the data center business five years from now.
Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. In the United States, Deloitte refers to one or more of the US member firms of DTTL, their related entities that operate using the “Deloitte” name in the United States and their respective affiliates. Certain services may not be available to attest clients under the rules and regulations of public accounting. Please see www.deloitte.com/about to learn more about our global network of member firms.
This publication contains general information only and Deloitte is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte shall not be responsible for any loss sustained by any person who relies on this publication.
Copyright © 2018 Deloitte Development LLC. All rights reserve