People often ask whether the offerings of cloud service providers (CSPs) are more or less secure than information technology (IT) services that are delivered through internal, on-premise implementations. I don’t believe that externally provided services are inherently more or less secure. Instead, I like to think of them as being “differently secure.” That begs the question: What’s different about security in cloud computing?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
It’s tempting to answer that question by saying “everything,” because of two fundamental changes that result from the use of external cloud-based services. The first is the creation of a technical architecture that spans the customer and vendor network and security boundaries. The second is the requirement for the sharing of responsibility for security operations between customer and vendor.
We already know that the use of a CSP will move responsibility for the physical control of facilities, data centers, servers and storage to the vendor. We also expect the vendor to implement encryption and access control that protects one customer’s data from another and from external attacks. However, there are several interface points that must be addressed in order to securely leverage the vendor’s capabilities. For example, how will network connectivity with the vendor be established? Will it be over the public Internet or will dedicated network circuits be required? What about identity management? How will authorized users be identified, have their privileges managed and ultimately be de-provisioned? Is there an enterprise directory that must be shared or federated with the CSP in order to properly integrate identity management with access control and authorization policies? Who will be authorized to “turn up” additional cloud services (and incur financial obligations) on the fly? In all of these cases, the requirements and implementation approaches must be mutually understood by the customer and the vendor.
From a security operations perspective, the vendor is clearly responsible for the physical security of their facilities. Additional security operations responsibilities will move to the vendor as a function of the cloud deployment model that is being utilized. The customer share of security responsibility is the greatest in the Infrastructure as a Service (IaaS) model. As one moves up the stack through Platform as a Service (PaaS) to Software as a Service (SaaS), the customer share of security responsibility shrinks and the vendor share of the responsibility grows. For example, in the IaaS model, the customer organization will continue to be responsible for ensuring security above the virtual machine layer. This includes things such as properly securing administrator passwords, enforcing least privilege and maintaining patch levels of additional software that is installed on the virtual machines.
Regardless of the deployment model, there are a variety of security operations functions that must be considered. We should ensure that the keys used to encrypt data are unique to each customer and understand who is responsible for generating and managing these keys. But let’s not forget about incident response. Who owns it? What is the process for identifying and responding to security breaches? Are there regulatory requirements for reporting breaches (or suspected breaches) that must be met and if so, who will make those reports? Who will be responsible for notifying impacted users if sensitive data such as social security numbers are breached? Access to security and event logs to is another important consideration. Will the customer need to access logs stored within the vendor’s infrastructure to support post-incident forensic analysis?
More resources about security in cloud computing
Of course, what we’re talking about here is what the experts have been doing for years to secure information systems: clearly understand the overall system requirements, technical architecture, users, privileges and data sensitivity in order to understand risks and to create the controls required to properly mitigate those risks. So now we might be tempted to say that there is nothing different about security in cloud computing. Certainly at a high level that is true, especially since responsibility for making the risk-based decisions regarding the system and the data it contains remain with the customer organization. But let’s look at one more aspect of the cloud model that drives changes to security: implementation.
In the cloud model, the word “implementation” takes on a different meaning than it does when building an on-premise system. Because of the shared, hybrid model that we are utilizing, we will need to answer most of the questions regarding technical architecture and operations before signing a contract with the vendor. What is critical from a security perspective is that the specific roles and responsibilities between the customer and the vendor be clearly defined and documented in that contract. To the extent practical, we should also tie vendor fulfillment of their responsibilities to financially-backed service level agreements (SLAs). What this means is that our “development team” will need to include representatives from outside the IT organization, such as legal, contracts and compliance. We will also need to make sure that these new members of our team understand the cloud model and the various considerations regarding shared responsibilities that have been identified. So we’d better start that education process as soon as we can.
So while the fundamentals of good security are unchanged in the cloud model, the hybrid technical architecture and sharing of operational responsibilities requires a change in our implementation approach. We must be rigorous in clearly understanding the vendor’s service offering and defining where responsibilities lie. We must then ensure that our contracts and SLAs reflect and enforce that shared responsibility.