Cloud computing risk varies among CSP service delivery models—SPI—and among the cloud computing deployment models—public, private, community or hybrid.
For example, a private cloud deployment model, using virtualized applications within an enterprise’s data centers or on leased third-party servers, is similar to traditional IT enterprises and the risk is also most aligned with existing traditional IT enterprise risk.
Conversely, in a public cloud deployment model, many clients collectively utilize the same CSP resources, sharing servers, applications and data files as needed by each cloud client. The location of the cloud computing server(s) is continuously changing, and the amount of data stored and the cloud clients storing it are in flux. The numbers of users, the shared levels of the operating stack, and the size and complexity of the virtual enterprise perimeter are much larger in the public cloud. As a result, risks from a public cloud deployment model are much more significant and different from traditional IT enterprise risks.
A large public cloud can be viewed like a large urban public transportation system. People are boarding and leaving trains, subways and buses continually, each with unique boarding points and end destinations. However, they all share the same system for their journey. They all bring personal data, valuables, PII and perhaps enterprise data on the notebook computers with which they travel.
Cloud computing clients maintain ultimate accountability for each security risk element. CSPs offer security risk administrative responsibilities on a graduated progression as their cloud services delivery model progresses, i.e., transitioning from an IaaS to a PaaS, then to an SaaS. In many cases, the immediate
responsibilities of risk controls are shared between the CSP and its clients. Demarcation lines between the CSP’s and the cloud computing client’s
responsibilities for shared risks vary (figure 4.1). These variations can be attributed
to the services delivery model used, the CSP vendor, the requirements of the prospective cloud computing client and the security classifications of the client data being migrated to the cloud computing platform.
In general, for the public cloud IaaS service delivery model, CSPs typically offer clients basic physical and administrative security provisions for their bare-bones cloud servers, i.e., physical security, intrusion detection systems (IDSs), intrusion prevention systems (IPSs), log management, and security information and event management (SIEM).
Figure 4.1—Varying Levels of Risk Management
Source: Universal Model, © Cloud Security Alliance. Used with permission.
If contracting a PaaS service delivery model in the public cloud deployment model, IAM application; configuration management; and governance, risk and management tools may be added as risk control services.
At the top of the service model stack, for SaaS offerings, CSPs may additionally offer performance monitoring, encryption and secure communication via virtual private networks (VPNs).
Between the immaturity of this industry and a current lack of cloud delivery standards, there is a wide disparity in the quality and maturity level of CSPs’ risk control offerings. Prospective cloud computing clients need to gain a complete comprehension of the scope and specific details of the security controls that the CSPs provide. Additionally, the expected risk responsibilities required of the prospective client must be specifically detailed. For shared risks, the specific hand- off points of risk control between the CSP and the client need to be detailed, down to the level of actual event scenarios. During the negotiations, the specific risk responsibilities and the CSP’s actual risk control capabilities need to be determined and a decision made as to whether they are adequate for the prospective cloud client’s risk control needs.
Tools and processes that are currently in place to improve enterprise efficiency and effectiveness—such as IAM, physical security controls, change management systems, systems and software development life cycles (SDLC), and disaster recovery—may be impacted by moving to the cloud. Also, current perimeter controls in place—such as data loss prevention (DLP), firewalls, IPSs and SIEM
Client Assumes All Data and Application
Security Risks IaaS Infrastructure as a Service APIs Abstraction Hardware Facilities Core Connectivity and Delivery APIs Integration and Middleware
Infrastructure as a Ser vice (IaaS) Infrastructure as a Ser vice (IaaS) Platform as a Ser vice (P aaS) Infrastructure as a Ser vice (IaaS) Platform as a Ser vice (P aaS) Software as a Ser vice (SaaS) Abstraction Hardware Facilities Core Connectivity and Delivery APIs APIs Presentation
Modality PresentationPlatform
Data Metadata Content
Applications
Integration and Middleware
Abstraction Hardware Facilities Core Connectivity and Delivery PaaS Platform as a Service SaaS Software as a Service
Data and Application Security Risks
systems—may not be as effective because data that were once monitored internally have been intentionally moved offsite. This shift requires changes in processes and procedures to ensure that security incidents are not occurring.
It is important that every enterprise considering moving to the cloud first
understand what information it holds, where it is and what the impact of a breach of that data would be. Information inventory, classification and labeling are important for all enterprises because information that is uncontrolled has the potential to be transformed from an asset to a liability. It is particularly critical that data owners understand the sensitivity of data currently stored within the enterprise that may be relocated to a cloud environment.
The following initiatives have significant implications for cloud computing.
IAM
Users have always been, and continue to be, a threat to enterprise data. Intentional and unintentional actions carried out by humans can put the enterprise in harm’s way. One way to control access to information is to implement an IAM system.
Such systems can control and manage access to data based on user role, data classification and data type, among other things. However, IAM systems are inherently vulnerable to the same threat that they are protecting against: insider attacks by employees or other trusted parties. For IAM to be an effective security measure, it must be updated regularly to avoid unnecessary accretion of privilege (violation of least privilege) and continuing access by individuals who no longer are entitled, such as terminated employees or contractors whose period of service has ended. Policies should exist and be followed for adding new users, changing existing user access and deleting users no longer needing access. This process holds true with cloud computing because unauthorized access to enterprise information resources is a prime cause for data theft or corruption of data integrity through modification or deletion.
The IAM risk consideration for a private cloud setting is similar to the
consideration for traditional enterprise IT settings. Since the data are segregated from all other cloud data and are often managed by the organization owning the data, access is typically restricted to users within the enterprise, business partners and e-commerce customers. However, the public cloud setting includes authorized users employed by the CSP, thereby allowing more people to handle information assets and increasing potential egress points.
By definition, public cloud clients share databases, sandboxes and applications—the multitenancy of resources. Within the multitenant databases, CSPs’ clients’ data are commingled; there is no guarantee that an enterprise’s data are not stored with the data of a competitor. In major public cloud SaaS offerings, stored data could remain unprotected if the client fails to apply an encryption solution before pushing the data to the cloud. Having commingled data in the public cloud environment
certainly highlights the need for secure access controls. Access privileges should be granted according to the concept of least privilege, allowing only the access to data and applications in the cloud and within traditional enterprise borders needed to complete job requirements.
It is important to control access to all identified data within the enterprise and in the cloud. As enterprises move to private and public clouds, the risk of unauthorized access does not change; however, the vulnerabilities and the likelihood of unauthorized access increase.