Cloud technology has leaped to the forefront of the technological world in the last 2 decades. One would be hard pressed to find an enterprise that has not implemented cloud technology in some form or another. Attention has now been shifted to how to optimize cloud resources to effectively mitigate risk. Moving data to the cloud introduces different types of risk due to dependency on cloud service providers (CSPs), complex technology, data residency beyond the physical control of the customer and a lack of transparency into many of the controls on which customers are expected to rely.
Since the onset of the cloud, its implementation has evolved considerably. CSPs have created many variations of cloud offerings to the extent that it would be challenging to provide an exhaustive list of all methods of implementation available today.
The US National Institute of Standards and Technology (NIST) Special Publication (SP) 800-145 The NIST Definition of Cloud Computing defines cloud computing as “A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configuration resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provide interaction.”1
The NIST Definition of Cloud Computing also describes the essential characteristics of cloud computing, which include on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service.
Beyond the essential characteristics, there are various cloud deployment models, including:
- Public cloud—The infrastructure is shared by multiple tenants and the cloud is open to the public. Anyone can utilize the public cloud by subscribing to it.
- Private cloud—The infrastructure is for the exclusive use of a single organization. The cloud may or may not be operated by the organization.
- Community cloud—Similar consumers can collaborate to set up a cloud in the form of a community cloud designed for sharing the infrastructure (e.g., government organizations can form a cloud for their exclusive use).
- Hybrid cloud—This is a mix of 2 different deployment models.
In addition, the following service models are available:
- Infrastructure-as-a-Service (IaaS)—The customer subscribes to compute, networking or storage resources offered by a CSP.
- Platform-as-a-Service (PaaS)—In addition to the building blocks described in IaaS, the customer also subscribes to tools, libraries, services and programming languages to run the application.
- Software-as-a-Service (SaaS)—The customer uses the application including underlying infrastructure and services provided by the provider.
There are many variants of cloud implementation that utilize all possible permutations of the deployment and service models.
Cloud Technology’s Impact on Risk
Information technology is a rapidly changing field. The impact of new technology such as the cloud on the technology risk landscape has never been so profound.
To mitigate this risk more effectively, it is important to understand which cloud computing factors have greatly impacted the risk landscape:
- The role of the third party—Outsourcing has played a significant role in the information technology field for many years. Third-party risk management is nothing new to technology risk professionals. However, the role played by CSPs has become far greater and more in depth. Depending on the deployment model used, this role can vary. If an organization is utilizing a public cloud model, the role played by the third party is far greater compared to other models because the cloud is completely owned and operated by the third party, while within a private cloud model there is a possibility that the customer organization will be responsible for ownership and operation. Similarly, the dependence of the customer on the vendor is greater when using a SaaS service model because infrastructure and applications are provided by the third party, while the IaaS model stipulates that only infrastructure is provided by the CSP. The complex relationship that can result from cloud arrangements puts the management of third-party risk on different footing for cloud technology.
- Technology—While virtualization technology is not a new concept, the extensive use of virtualization in a cloud environment gives rise to new technology risk. New hardware and software elements such as the use of hypervisor, utilization of a management plane to configure the underlying hardware, software defined networks, serverless computing and/or Infrastructure as Code (IAC) introduce new risks which must be considered in the overall risk assessment.
- Joint ownership of controls—While the use of third-party vendors is not new in the technology space, it is the degree of integration in the operation of the controls that makes cloud technology different from a risk perspective (figure 1).
Figure 1— Cloud Control Ownership Model
For example, consider backup and recovery control. Most CSPs offer multiple options for storing cloud customers’ data during PaaS deployment. There may be a scenario in which the customer does not avail itself of a CSP’s backup services and is, thus, responsible for creating backups, in which case, the provider is responsible for the redundancy of compute resources and the customer for everything else. Alternatively, a customer can opt to have backup services performed by the CSP at cost. In this case, the customer is responsible for identifying the backup requirements and recovery point objective (RPO), while the cloud provider is responsible for managing backup routines, backup security and backup testing. Thus, various backup and recovery options are available to customers. The responsibility of the customer and the provider varies by circumstance.
In the case of some controls such as identity and access management-related controls or encryption-related controls, the customer and provider responsibilities are so interwoven that a one-size-fits-all approach will not work, thus making it difficult to assess and analyze the control effectiveness and, in turn, the risk.
While the use of third-party vendors is not new in the technology space, it is the degree of integration in the operation of the controls that makes cloud technology different from a risk perspective.
- Subcontractors—Most CSPs heavily utilize the services of other subcontractors. Monitoring the use of subcontractors further complicates things. Imagine a SaaS provider that hosts data and utilizes the compute services of a certain CSP and backs up the data using a different CSP. For the customer, this creates multiple stakes of control, each operated by different vendors with ambiguous responsibility models.
- Data location—The location of data is uncertain in a cloud environment. In fact, the notion of “the cloud” suggests this indirectly. In certain countries, there are legal and regulatory requirements related to the location of data. The nature of the cloud worsens the compliance nightmare in such cases. Some CSPs allow the organization to select the location of the stored data. However, there are further complications. For example, some PaaS services utilize temporary data storage and CSPs may be unable to ensure this location as the cloud service is designed to make use of compute and storage resources to suit the processing requirements of any location.
- Ability and willingness of cloud providers to educate customers—Most CSPs are interested in complying with security requirements, well versed in regulatory and legal requirements of different geographies, and eager to support customers’ economic interests. However, this is not true universally. Smaller CSPs may not be aware of the more complex legal and regulatory requirements. They may be unsympathetic toward extensive assurance requests by certain sensitive industries. At times, customers spend considerable time explaining the control requirements to smaller players. Even bigger CSPs are only willing to be transparent up to a certain point. Some CSPs may stonewall customers with complex service level agreements (SLAs) and right-to-audit requirements. Understandably, CSPs are driven by economic interest and are not inclined to customize the assurance requests of a large customer base. This makes risk analysis and assessment challenging.
Ultimately, cloud technology warrants far deeper analysis of the control environment and risk management approach when compared to other new technology initiatives.
Recommendations for the Technology Risk Professional
To address the challenges posed by cloud implementation, technology risk professionals must make changes to their approach to technology risk that account for the following considerations:
- Mindset—This recommendation could be a bit surprising and slightly controversial. Cloud implementation is a reality. The benefits of cloud technology have outweighed its perceived risk. CSPs have also accepted that stronger security controls and better risk management processes make more economic sense. Technology risk professionals must accept that they will not get the same level of visibility into the control environment when data move to the cloud. Customers must rely on vendors to protect their data. Risk professionals should devote more energy to customizing their own controls and developing thorough assessment techniques to ensure reasonable visibility. Technology risk professionals must accept that they will not get the same level of visibility into the control environment when data move to the cloud.
- Training for risk professionals—The cloud is a complex mix of different technologies and it is continuously changing. When risk professionals are not adequately trained in cloud fundamentals, they tend to apply an on-premises mindset to the cloud, resulting in an ill-suited risk management approach. Training for risk professionals should go beyond the standard training offered by large CSPs. Such training should be designed collaboratively by cloud experts, CSPs and risk professionals to ensure that all bases are covered.
- Checkpoint design—It is difficult to remedy any gaps once an application or service has moved to the cloud. There should be list of a minimum set of controls in place before the application or service moves to the cloud. For example, if the application stores and processes confidential data, then it is better to confirm the proper level of encryption controls with the cloud provider before the application is onboarded to the cloud. Will the customer rely on a CSP’s key or would they use their own key for encryption? Or would the CSP be better equipped to support the customer’s higher availability requirements, especially considering the services offered by the CSP may not be supported in all its data centers? These questions should be answered before a service moves to the cloud. Such checkpoints should be built into the cloud curation process to ensure that applications move to the cloud only after ensuring that the proper set of controls is in place.
- Customization of the control catalog—Many risk professionals make the mistake of using the same control catalog for cloud implementations. While the fundamental nature of the controls has not changed, the way the controls are operated has changed. For example, consider a control that is used to test on-premises applications once a year for disaster recovery (DR) purposes. While applications can still be tested once they have been onboarded to the cloud in a PaaS or IaaS environment, the control may need to be broken up into a number of subcontrols to clearly articulate what can be tested by the user without participation from the cloud vendor and which part of the control would be integrated with the published DR reports of the cloud vendor.
- Vendor relations—Ultimately, not everything can be determined by an SLA or audit clause. Developing good relations with the vendor is important for risk management professionals. Both the provider and the customer should treat the entire risk management exercise as a mutually beneficial. Regular meetings with the vendor, the exchange of ideals and mutual trust can help quickly strengthen the control environment.
- Evaluate third-party compliance reports—Many CSPs, especially larger providers, become third-party assured to demonstrate the effectiveness of the controls. It is important to make use of compliance reports to gain insights into a CSP’s control environment. These reports may include an SOC2 report, penetration testing report, Payment Card Industry Data Security Standard (PCI DSS) report, Cloud Computing Compliance Criteria Catalogue (C5) report or International Organization for Standardization (ISO) standard ISO 27001 certification. Each report or attestation has a different focus. It is also important to understand the scope covered by the report. For example, if data reside in a Central India data center and that data center is not covered by the SOC2 report published by the CSP, then one may not want to rely on such an SOC2 report for assurance purposes. Further, these reports might be published or refreshed at regular intervals. It is important to understand and keep track of the frequency with which reports are released and modified. Most important, the customer should map its own control catalog with the controls covered by such a report to ensure that coverage is adequate.
As the technology risk function digs deeper into cloud risk, there may be other changes necessary for implementation.
Fortunately, guidance is available in the form of various publications, including Cloud Security Alliance’s (CSA’s) Cloud Control Matrix version 4.2 It is composed of 197 control objectives divided into 17 domains. It not only includes new controls to be included as a result of implementation of cloud technology, but also shows the division of responsibility between the CSP and the cloud customer. Implementation and auditing guidelines are also available. NIST’s Cybersecurity Framework version 1.13 includes voluntary guidance based on existing standards, guidelines and practices for organizations to better manage and reduce cybersecurity risk.4
Conclusion
The approach to identifying, assessing and analyzing technology risk should be customized due to several factors that differentiate cloud implementation from on-premises implementation. The impact of cloud technology may vary by organization depending on the cloud model and method of deployment.
The technology risk function should not only undergo a mindset change to assess the risk related to cloud technology, but also at a more granular level, change the control framework to ensure that cloud related risk is adequately addressed and mitigated.
Endnotes
1 National Institute of Standards and Technology (NIST), Special Publication (SP) 800-145 The NIST Definition of Cloud Computing, USA, September 2011
2 Cloud Security Alliance, Cloud Controls Matrix (CCM) v4, June 2021
3 National Institute of Standards and Technology, Cybersecurity Framework Version 1.1, USA
4 National Institute of Standards and Technology, “Getting Started,” USA, February 2018
Editor’s Note
Hear more about what the author has to say on this topic by listening to the “Achieving Effective Cloud Risk Management” episode of the ISACA® Podcast.
Upesh Parekh, CISA, CRISC
Is a governance, security and cloud risk professional with more than 15 years of experience in the banking and finance domain with knowledge of risk management methodologies. He works for a leading wealth management institution and is based out of Pune (India). Parekh has served on an ISACA® publication subcommittee in the past and helped review ISACA’s Certified in the Governance of Enterprise IT® (CGEIT®) and Certified in Risk and Information Systems Control® (CRISC®) certification exam review manuals.