Editor’s note: Throughout Cybersecurity Awareness Month in October, the ISACA Now blog will publish new posts on hot security topics each week. For additional ISACA cybersecurity resources, visit our Cybersecurity Awareness Month page.
Cloud security breaches consistently make news headlines. Yet, the stories of these breaches are often framed with vague explanations — a “misconfigured database” or mismanagement by an unnamed “third party.” The ambiguity that surrounds cloud computing can make securing the enterprise seem daunting. Concerns about security have led some CIOs to limit their organizational use of public cloud services.
However, the challenge exists not in the security of the cloud itself, but in the policies and technologies for security and control of the technology. In nearly all cases, it is the user, not the cloud provider, who fails to manage the controls used to protect an organization’s data. “CIOs need to ensure that their security teams are not holding back cloud initiatives with unsubstantiated cloud security worries,” says Jay Heiser, Vice President Analyst, Gartner. “Exaggerated fears can result in lost opportunity and inappropriate spending.” CIOs must change their line of questioning from “Is the cloud secure?” to “Am I using the cloud securely?”
Acquiring a cloud service can be straightforward. We sign up with our preferred Cloud Service Provider (CSP) and soon thereafter are able to immediately deploy services and systems in a relatively simple matter, especially if we’re using the services for personal matters. However, things can get tricky if you have been assigned or are responsible to leverage a CSP as part of your overall cloud strategy. Even at initial blush, with all the managed migration services and self-help migration tools at one’s disposal, choosing and migrating to a CSP may seem simple and not overly complicated.
Beginning with Virtual Machines in the cloud was a relatively simple concept to understand and accept back when cloud computing was fresh and new around 2006. The industry was already familiar with the responsibility between the host, guest operating systems and virtualization. To this extent, when organizations were questioned regarding implementation of their cloud workloads, there was little to no argument when customer responsibility was situated on virtual machines. However, as cloud services got more complex, the shared responsibility model was introduced.
The shared responsibility model is a cloud security framework that dictates the security obligations of cloud computing. The shared responsibility model is one of the fundamental elements of a successful cloud deployment. A proper implementation of the shared responsibility model helps achieve several objectives, such as taking advantage of the nature of the cloud, being efficient and economical with resources, and having clearly defined delineations between processes, people and technology. The model below depicts the Shared Responsibility model.
The shared model’s intent is to help relieve the customer’s operational burden as the CSP operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software, as well as the configuration of the CSP-provided security firewall.
In the shared responsibility model, customers need to carefully consider that the services they choose as their responsibilities vary depending on the services used, the integration of those services into their cloud environment, and any applicable laws and regulations. The nature of the shared responsibility also provides the flexibility and customer control that permits the deployment. As shown in the figure above, the differentiation of responsibility is commonly referred to as Security “of” the Cloud versus Security “in” the Cloud.
The Customer Responsibility Matrix seeks to help provide clarity to the controls that may be shared between the cloud consumer and the CSP. However, in the majority of cases, the CRM is either an afterthought, or developed once but not diligently maintained and/or managed. In part, the inattention to the CRM is a result of the pace at which technology moves, which is not an excuse, but something we all need to consider and be more cognizant of. As we initially pointed out, cloud consumers are still puzzled and misinterpret what they themselves are responsible for within the cloud, especially if it happens to be an innovative service that delivers a mixture of features. The customer can easily gain a false sense of security.
New innovative abstracted services continue to introduce new ways of interpreting the responsibility between customer(s) and CSPs. Even when Customer Responsibility Matrixes (CRM) are provided, most if not all CRMs do not go to the level of granularity required for organizations that are subjected to federal mandates or regulations to aid in properly configuring the leveraged systems and services.
And so, cloud consumers continue to consume the innovative new services with the same type of false assumption as when cloud computing was first adopted, that the customer would simply be able to begin leveraging the managed service in a turn-key manner where no additional configuration would be required. As we know now, the assumption, for the most part, is incorrect. Fully managed cloud services do exist, which provide clear shared responsibility model(s) and make a diligent effort to notify the customer of their responsibility. However, it would be unfair to state that the majority of the CSPs provide this level of tailored courtesy to all customers.
As cloud security breaches began to occur at no fault of the CSPs, the misinformed majority continued to misinform others of the “risks” of the cloud, when almost every cloud security breach has occurred due to a customer misconfiguration or non-configuration (running systems with all default configurations). Hundreds of online arguments have taken place regarding configurations and what needs to be done, and what the customer should be provided out the gate, which is commonly referred to the as the “baseline configuration.” To use the NIST definition of a baseline configuration: “A set of specifications for a system, or Configuration Item (CI) within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.”
You can think of the baseline configuration as the system defaults. When you spin up/launch a service within the cloud and click “next” without configuring anything and use the defaults for all options, you will ultimately be deploying the system/service with the default configuration baseline (with no options selected). However, all those options you just skipped are also your responsibility as the customer. So, if you were to deploy a workload with all the default options and were given the option to configure multiple aspects of your service such as encryption, and your system is breached due to no encryption, you are and will be liable, as you were given the option, but ultimately did not configure encryption to be enabled. What we just described is essentially the Shared Responsibility Model. If your organization failed to properly secure the cloud system and was breached, you, the customer are ultimately responsible – not the cloud service provider.
