Shared Responsibility on Cloud
The rapid adoption of the cloud simplifies infrastructure maintenance but also introduces new approaches to addressing security. CIOs and Security Experts need to recognize this and incorporate stringent measures to ensure that the organization’s IT infrastructure is safeguarded at all levels.
Depending on the organization’s cloud infrastructure, the responsibility of security lies with either the “Customer”, which is the organization using the services, or the “Cloud Service Provider (CSP)”, the entity that provides these services. While the CSP is responsible for the security “of” the cloud, the Customer would be responsible for security “in” the cloud. But what does this actually mean and what implications does it have for the CIO? The answer is nuanced and needs analysis of various deployment models that CSPs offer for customers for various services.
IaaS, PaaS, and SaaS: What are they and how do they influence the shared responsibility of cloud infrastructure?
Let us examine the schematic shown in Figure 1 below.
Figure 1 Shared Responsibility Model
It is crucial to understand the three different models of cloud deployment and their impact on the contract between the Customer and the CSP.
The first is the Infrastructure as a Service (IaaS). In this model, the Cloud Service Provider, or the CSP, provides the basic set of hardware, systems, and networking infrastructure that is necessary for the customer to host their own environment on top of. In this model, the CSP is predominantly responsible for maintaining the physical security of the infrastructure. Depending on service agreements, the CSP could additionally be responsible for the security of host infrastructure and network controls. All other security controls that are needed to run the hosted applications lie with the customer.
In the Platform as a Service (PaaS) model, the Cloud Service Provider makes provisions for additional components compared to a pure IaaS setup. These could include the operating system, certain middleware, and runtime environments that would require additional security endpoints to be managed. In such cases, the CSP ensures the security of the core infrastructure and may additionally secure services that could be abstracted to the application layer – such as those involving identity and access management and other application-level controls.
Finally, the Software as a Service (SaaS) model is one where the software is provisioned by the CSP as a fully managed service. All popular SaaS applications that are provided on the cloud are classic examples of this configuration. In this case, the CSP takes over the responsibility of securing the infrastructure and the application, while the customer needs to define data and application access controls.
Figure 2 Summary of the shared responsibility
What is shared responsibility? Us versus them: It’s evident from the three deployment models described above that responsibility of security in the cloud is not always as clearly demarcated as it should be. This is a critical risk for the enterprise because, in a typical IT landscape, applications, and infrastructure are deployed in a complex matrix involving all the above models, including, in many cases, legacy on-premise applications. A customer’s IT landscape is only as secure as its least guarded endpoint. Therefore, it becomes critical for CIOs and organizations’ boards to treat this topic with the importance it deserves.
Industry standards: How do the major cloud service providers define “shared responsibility” and why it’s not all black and white? What's key in enabling a robust and secure cloud environment is understanding where your responsibilities begin and where your provider's responsibilities end. The answer isn’t always clear-cut, and definitions of the shared responsibility security model can vary between service providers and can change based on whether you are using infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS). Let us take a look at a few industry leaders and their shared responsibility positions.
The Amazon Web Service (AWS) security model claims responsibility for “protecting the hardware, software, networking, and facilities that run on AWS Cloud services”. On the other hand, Microsoft Azure claims security ownership of “physical hosts, networks, and data centers.” Both the cloud giants state that your retained security responsibilities depend upon which services you select.
While what's mentioned above the dotted line is almost identical for both or even other CSPs, yet shared responsibility Service Level Agreements (SLAs) are notorious for fine prints that are open to interpretation. The security responsibilities vary dramatically from one CSP to another and the type of service you sign up for. The complexity and risk increase manifold in a multi-cloud environment. Each environment, application, and service requires a unique approach for security assessment and monitoring.?
Could there be a framework to model and minimize this security risk?
A vendor-agnostic approach to shared responsibility: Locuz has developed a shared responsibility model that organizations can use to evaluate different offerings from various CSPs. As shown in Figure 3, this model relies on concepts rather than terms mentioned in a typical Service Level Agreement (SLA) and is, therefore, more robust.
Figure 3 CSP approach to shared responsibility
When you start discussions with your Cloud Service Provider, this diagram can help you structure the dialog on the aspect of security. Let us take a deeper look.
Your Share of Cloud Security Responsibilities
"YOU" are always responsible for whatever is under your direct control. But as we discussed earlier, these could include different aspects of the cloud stack depending on the relevant deployment model. Figure 4 below summarizes your sphere of responsibility.
This illustration covers the respective “layers'' in any cloud deployment, regardless of the vendor, and is therefore applicable for a wide variety of situations you may find yourself in. The emphasis is on your responsibility as a customer and why you need to wield control over it.
Figure 4 Customer approach to shared responsibility
Information and Data: You need to ensure that you have complete control over your information and data, such that all data access is yours by design and your provider has no visibility into your data.
Application Logic and Code: It is your responsibility to secure your intellectual property such as patented codebase and applications through the entire application lifecycle. This will include security for your internal codebase from being misused, including security aspects in testing through the development and integration phases, securing production access, as well as maintaining the security of all connected systems.
Identity and Access: You are responsible for all facets of your identity and access management (IAM), including authentication and authorization mechanisms, single sign-on (SSO), multi-factor authentication (MFA), access keys, certificates, user creation processes, and password management.
Platform and Resource Configuration: When you spin up cloud environments, you control the operating environment. Your control maintenance would depend on whether these environments are server-less or server-based. For example, a server-based environment may require more control over security such as OS and application hardening, maintaining security patches, etc. In essence, your server-based instances in the cloud behave similar to your physical servers, and function as an extension of your data center.
For serverless environments, on the other hand, your provider’s control panel gives you access to configuration setup, and you are completely responsible for ensuring the configuration is adequate to prevent any unauthorized access to the environment.
Cloud Security Posture Management:? You are responsible for ensuring a regular check on your cloud health. Locuz’ Cloud Security Posture Management routinely and constantly checks for misconfigurations that can lead to data breaches and leaks, while recommending any necessary changes on a continuous, ongoing basis.
Threat Intelligence: The cyber threat landscape evolves rapidly, and threats to the cloud are not an exception. It is your responsibility to procure cloud security solutions for threat intelligence to identify, monitor, and protect against the latest cyber threats to your critical cloud infrastructure.
Cloud Connectivity: Additionally, you maintain the responsibility for securing everything in your organization that connects with the cloud. This could include your on-premises infrastructure, user devices, owned networks and applications, and the communication layers that connect your internal and external users to the cloud and each other.?
Finally, you will need to set up your own monitoring and alerting for security threats and incidents in addition to the above-mentioned measures. Organizations have found it useful to wargame scenarios of security breaches and plan the appropriate response. These responsibilities are yours regardless of the CSP you choose.
Application Developers and CIO’s should consider the implications of shared responsibility and ensure that there are no security blind spots, where one thinks that the other is taking care of security. The best practice would be to schedule regular security audits across all areas. Locuz has provided these services such as Security Posture Assessment to clients that have benefited tremendously and have been able to plug vulnerabilities before any mishap.
Originally Published on www.locuz.com