2

Understanding Shared Responsibility Model for Cloud Security

As your business undergoes digital transformation with the foundation of multi-cloud, it is necessary to rethink your security architecture and methods of achieving continuous security. This approach to secure digital transformation is different from the past methods taken to secure traditional monolithic enterprise applications. In place of securing applications that were running inside their own data centers, enterprises need to deal with a heterogeneous ecosystem. For applications modernized and migrated to the cloud, there is a need to provide the assurance that the cloud is a secure, trusted platform. These applications also need to securely integrate with existing applications. Addressing hybrid cloud security concerns requires a strategic approach that’s aligned with the enterprise’s strategic objectives of a risk-based approach assuring total data protection and continuous security.

We will cover the following topics in this chapter:

• A strategic approach to cloud security
• A shared responsibility model for cloud security
• Cloud security domains
• A pattern-based and zero-trust approach to addressing hybrid cloud security

A strategic approach to cloud security

A strategic approach to cloud security should be driven by a governance and control framework created with the enterprise’s risk appetite in mind.

Enterprise security teams led by the Chief Information Security Officer (CISO) define the policies and controls, as well as managing them against the IT budget. They leverage an IT Governance, Risk, and Compliance (GRC) framework that defines the policies and assesses the controls in place to meet the audit and compliance requirements. The audit and compliance set are based on industry needs and regulatory requirements. The risk management part of the framework continuously assesses the effectiveness of the controls against the business goals. The following diagram shows the GRC control framework, which includes the policies, controls, audit, compliance, and risk management:

Figure 2.1 – GRC for the cloud

This also includes threat management and the continuous monitoring of multi-cloud environments. These controls need to be quantitatively and qualitatively measured to ensure continuous security. Achieving continuous security involves the cycle of defining, protecting, detecting, and responding on an ongoing basis. The leadership team manages this cycle against the business goals.

The cloud security strategy should also be guided by a set of principles that include but are not limited to the following:

• Shift left security for a secure by design approach – Ensure that security is included early on in the cycle, at the stage of conceiving the solution architecture and design. Currently, security is included toward the end at the time of deployment and operations. Addressing security issues needs to begin at the start of development, not at the end. A change to this approach is recommended.
• Simplified and automated security management – It is recommended to keep the policies and controls consistent across all environments. A centralized security and compliance center to define, enforce, and monitor security across hybrid multi-cloud environments is recommended. Build security solutions that are easy to consume and manage through automation. This will also help reduce the cost of security from an operational perspective as well.
• The principle of least privilege – This principle from the traditional software development model is relevant to the cloud world as well. Security privileges should be just enough to perform the activities. There is a need to continuously keep checking to ensure that there is no overprovisioning of privileges to any user or system.
• A cloud-first approach – It is recommended to leverage the controls that are available natively in the cloud to secure the workloads. Doing so means that security services can be consumed by the developers, similar to other cloud services. This consumption model also helps developers to easily secure their application without being security experts. For the security capabilities needed, the model is to look at the cloud first and then build on top of it with other partner products or technologies. The security focal for the cloud application can additionally leverage an existing homegrown or partner capability to perform end-to-end security management.
• Complete data protection – This principle recommends taking a data-centric approach to security. This involves three steps. The first one is to do data classification and understand the different types of data in the enterprise and define the protection needed for each type of data. The second step is to protect classified data based on security and compliance requirements. The protection would involve building defense-in-depth patterns supporting various access levels for different datasets. The protection implements security controls that ensure data is protected at all times. Finally, data access monitoring confirms that there is no unauthorized use and enables rapid corrective action if a breach or anomaly is seen.
• Zero-trust models – This is a set of emerging principles that can guide an enterprise security strategy. In this model, we switch from traditional perimeter-and content-based security to context-and workload-based security. This model moves from assumed trust to a zero-trust approach, where everything, such as users, devices, networks, applications, and data, is treated as untrusted elements. Trust must be established and verified instead. Verifying the access to provide to the resources is based on the context and the business needs. This model assumes a security breach can happen anytime and looks at ways to continuously improve the security posture.

A shared responsibility model

Depending on the cloud consumption and delivery models, the division of roles and responsibilities will vary. As discussed in the following diagram, the flexibility of each model varies, as does the responsibility for ensuring the security of the components. You will see that when we go from IaaS to SaaS, the responsibility of the cloud provider increases with consumer flexibility decreasing. It is necessary to understand the overall stack and what is being consumed from the cloud. Accordingly, we have to draw the line to determine what aspects would be taken care of by the provider and what needs to be covered by the consumer. Security of the overall cloud solution is a joint responsibility:

Figure 2.2 – The shared responsibility model and cloud delivery models

An IaaS model

In the case of IaaS, the cloud provider handles the traditional in-house responsibilities of the enterprise to provide storage, the compute, and network services. This includes the operational management of the physical facilities and the infrastructure (network and servers hosted in this environment). The enterprise consuming the IaaS will be responsible for the architecture, deployment, security, and operational management of the workload deployed on top of the infrastructure. Again, where you draw the line to divide the roles and responsibilities will depend on the service and contract with the cloud provider – for instance, the roles and responsibilities for bare-metal servers and those for virtual servers could be different. In the case of a bare-metal server, enterprises have exclusive rights to dedicated physical servers. They can install operating systems of their choice or bring their own, including bringing their own virtualization strategies and virtual appliances. This makes it easy to extend the enterprise’s on-premises virtualization strategy to the cloud, independent of our virtualization options. So, with IaaS, similar or flexible options to what enterprises have in their own data centers are available. However, certain tasks will need a cloud provider’s support, such as adding physical memory or swapping hard drives through a documented change management process agreed upon with the enterprise.

If an enterprise is consuming compute services such as virtual machines, the management of the underlying (physical) host and hypervisor including its configuration and patching lies with the cloud provider. The hypervisor is only accessible over the private management network maintained by the cloud provider. It is the cloud provider’s responsibility to monitor the hypervisor’s health and security including applying critical patches and upgrades to ensure the health of the virtual machines on the host. This might involve migration of the virtual services across hosts to meet the security and health requirements or support maintenance of the underlying physical server. The maintenance and update of the software and operating system running inside the virtual machine shall be the cloud service consumer’s responsibility.

Similarly, in the case of a network, the various segments would include public, private, and management networks, and the private backbone for the data center. Cloud providers manage the configuration and management of the physical devices including the switches and routers that provide network structure and connectivity.

In the IaaS model, the provider therefore takes care of the security of the physical environment, and the data center, and makes the servers available for use by consumers. The security of the workload and managing access to it is the consumer’s responsibility.

A PaaS model

When it comes to PaaS, the provider will provide the middleware services. These include capabilities such as messaging, a database, a cache, and functions made available as a service. In this case, the provider takes care of end-to-end security for the platform services. Designing the threat management for the platform, and taking care of patching the middleware, as well as the underlying server and system infrastructure, is the responsibility of the provider.

The PaaS consumer is responsible for the security of the application and data built or run on top of this platform. Security for any sensitive or Personal Identifiable Information (PII) data that the application is collecting, processing, or storing in the platform will be the responsibility of the cloud consumer. Meeting the regulatory requirements from the data and application perspective will also be the cloud consumer’s organization’s responsibility. The provider organization can help provide necessary supporting evidence or the provider can be contracted by the consumer to manage security or assist with regulatory compliance and reporting tasks.

A SaaS model

In the model, the provider takes on all the pain of securing the service from end to end. Right from infrastructure, middleware services and the application or workload security are all managed by the provider. The threat, vulnerability, and patch management of the entire stack is the responsibility of the provider. Clients get the true gain of a pay-as-you-go model with SaaS without having to worry about any of the security operational aspects. But the security of the data stored within the SaaS service would still be the responsibility of the cloud consumer. Continuous data protection and managing the keys used for encryption of the data will be the consumer’s responsibility. Also, the operational aspects related to data access monitoring and protecting the IP are the consumer’s responsibility.

The shared responsibility model

Enterprises need to define and establish the responsibility matrix related to how they are going to implement the strategy for meeting their cloud security requirements. Cloud security is a joint responsibility between the cloud provider and cloud consumer organizations. As we discussed in the previous chapter, there are several actors typically involved in building and operating a cloud solution, their roles, responsibilities, and the relationships between these actors. There are specific roles responsible for executing the strategy. Once an organization has started with the cloud, then some typical actors are involved in the design as well as day-to-day operational aspects of cloud security. These roles across the cloud providers and consumer organizations include the following:

• Chief Information Officer (CIO) – Defines the high-level information security and compliance policies for the enterprise. This role also communicates with C-level executives on the critical decisions concerning the technological strategy and component selection.
• CISO – Puts in place the framework to implement the policies for the enterprise. We also see a variation of this role as a Business Unit Information Security Officer (BISO) who is responsible for implementing the policies and controls for their business unit or the systems under their control – middleware, servers, architecture, and the technologies and tools to use for this. The CISO needs to understand the security management and compliance aspects, as well as the applicable standards leveraged as part of the implementation.
• Security focal – This role executes the plan created by the CISO and ensures the application or workload level security. The tasks include performing security scans, setting up tools, monitoring results, investigating risks or issues identified, opening tickets for fixes, and collaborating with development or operations teams. The tasks also include vulnerability management – every time a patch is released, they need to check whether it is relevant, install (or assign) it, and make sure it is done on time.
• DevOps/SRE – In teams where there is no dedicated security focal for the projects, the DevOps professional or the Site Reliability Engineer (SRE) works on the tasks to implement the recommendations and reports status back to the CISO or security analyst.

Security and compliance requirements don’t change when you move your workloads to the cloud. A hybrid multi-cloud application involves many components across the IaaS, PaaS, and SaaS stack consumed from different clouds. Shared responsibility is a matrix that defines the roles and responsibilities of the provider and consumer. This captures the security obligations and the accountability of each stakeholder. Each participant and the roles of the cloud provider and cloud consumer organization are responsible and accountable for different aspects of security. The teams must work together to ensure nothing falls through the cracks or is left unattended. The shared responsibility model and management of risks and compliance could become the core deciding factors when planning multi-cloud adoption.

This responsibility assignment matrix is typically captured in what’s called a RACI model (https://en.wikipedia.org/wiki/Responsibility_assignment_matrix). This matrix defines who would perform what task and the activities are grouped under a role:

• R = Responsible – This role performs the task or does the work to complete the task. A RACI table is incomplete without the responsible role filled in, while other roles may be optional.
• A = Accountable – This role ensures that the task is completed and is answerable to authorities on any queries on the task. The role arranges for the environment and prerequisites required for the task to be completed. Work allocation and the delegation of tasks are also the responsibility of this role.
• C = Consulted – Opinions are taken here, or this role brings in subject-matter experts for making decisions, as well as determining best practices.
• I = Informed – This role is generally kept in the loop or informed about the progress of the task. This communication would be more from a business, technology, regulatory, or compliance perspective.

The RACI matrix for a secure solution should cover all components that need to be secured and call out the responsibility of the users involved to bring together the roles and responsibilities into a single page. This could be done in two ways, either taking a resource-centric approach or taking a security activity-centric approach.

An example RACI matrix for a resource-centric approach is given in the following table for a PaaS model. We take the service as the cloud resource and list out the areas to be covered for the end-to-end security of the service. Then, the responsibilities are called out for each aspect to be covered to secure the resource:

Table 2.1 – A resource-centric RACI model

An example RACI matrix for an activity-centric approach is given in the following table. In this approach, we take the service as the cloud resource and list out the areas to be covered for the end-to-end security of the service. Then, the responsibilities are called out for each aspect:

Table 2.2 – The activity-centric RACI model

Simply stating that the cloud provider will take care of everything when it comes to audit and compliance is not enough. The organization’s GRC program has to clearly call out the information that the cloud provider needs to meet the audit and compliance requirements. These continuous compliance audits could be done by third-party auditors and the enterprise needs to collaborate with the cloud provider to provide evidence of the best practices for the end-to-end workload compliance requirements. This could be in the form of third-party-lead risk assessments, audits, and control reviews to ensure that the underlying foundation layers meet the security and compliance requirements and are managed to the highest standards. It’s important that the various responsibilities are clearly documented in the cloud provider contract and are subject to audit. And the business and IT system owners need to have a good understanding of who is responsible for what security tasks. This also needs to include who does what in the case of a security incident.

The collection of these audit records or evidence may be automated for different cloud resources and services. The cloud provider can then share this material on demand with the consumer organizations through a web portal and API. This gives full visibility into the efforts and management of the environment by the provider. The enterprise consuming the cloud resources can import this information into their GRC dashboard or tools to make it easier for their own security and compliance needs.

The activities to be performed at each phase of the cloud project need to be planned jointly by the cloud provider and consumer. The phases would include project kick-off, engagement planning, design, development, testing, and operations.

Cloud security domains

Addressing hybrid multi-cloud security is a multi-layer, multidimensional problem to be solved. For an end-to-end security model, we need to understand each of these security domains and define the dimensions for each of the domains. We should be able to specify the security controls or processes for each domain and how to operationalize them to achieve continuous security. This model takes into account the need for a continuous integration (CI) and continuous delivery (CD) model in the cloud-native world. The security organization also needs to be aligned with this culture.

The following diagram shows the various security domains to be considered from a multi-cloud perspective, as well as the capabilities needed for security operations to support the CI/CD model for the cloud:

Figure 2.3 – Cloud security domains and components

The following are the domains to be considered:

• Identity and Access Management (IAM) – Identity is at the edge of all solutions. The IAM domain includes authentication, authorization, and audit. Authentication identifies the user or system and provides access to cloud resources, services, and applications. Authorization determines the level of access and operations that can be performed on the resources. IAM needs to be applied across all layers in the stack – the infrastructure, middleware application, and data. In multi-cloud environments, it needs to account for the different types of users and systems – including cloud users and application users. The aspects of managing authentication and access policies for cloud users is called cloud IAM and is called application IAM for an application.
• Infrastructure security – The infrastructure security domain includes providing a secure compute, storage, and network. Compute resources include bare-metal servers and virtual machines, as well as containers provided as a cloud service. The network is another critical aspect of the infrastructure. Securing the network would involve network isolation and protection and providing secure connectivity. Building secure zones and monitoring and responding to network threats such as Distributed Denial-of-Service (DDoS) are also requirements in this domain. There are different types of storage such as file storage, object storage, and block storage leveraged in the cloud ecosystem. The patterns for protecting the data stored in these storage types are part of the infrastructure security domain.
• Data security – This encompasses the aspects of how we protect data at rest, in transit, and in use. This leverages encryption standards, technologies, and tools, along with key management. In a hybrid cloud world, key management patterns are an important consideration, as they provide the consumer the ability to be in control of their data through patterns such as Bring Your Own Key (BYOK) and Keep Your Own Key (KYOK). The required steps to protect highly sensitive data, such as encrypting it inside the application as well as while in use, are captured as data protection patterns. Interservice communication requires mutual authentication and securing communication channels and pipelines. This domain also requires certificate management capabilities that address the protection of data in transit, as well as providing better visibility into certificate life cycles and proactively managing certificate expirations to avoid service outages.
• Application security – This domain deals with ensuring the applications are free of vulnerabilities and protecting the application. Modern applications include applications that leverage modern technologies to provide a unique experience to end users. Enabling the secure use of these exponential technologies, such as IoT, blockchain, serverless functions, and the use of quantum computing, falls into this security domain. This includes applications that can be accessed through different channels such as the web, mobiles, or kiosks. Developers need to understand the risks of cloud resources being made available to end users through different application channels and devices. The steps to implementing authentication, the verification of channels and devices, and risk-based authentication are part of application security. Digital transformations built on the cloud also have an increased demand for a business platform that is enabled through the use of APIs. Building and scaling secure APIs is part of the application security domain. Security for the integration infrastructure, enabling connectivity with other applications, also needs to be included in this domain.
• DevOps – This domain includes the planning, building, testing, deployment, and management activities of software development and operations. The threat modeling aspects to identify malicious actors and the impact of their actions on the system start in this domain. This includes the proactive identification of threats and attacks that can lead to security incidents or loss of sensitive information. The team needs to plan for secure programming, configuration, and integration as part of the DevOps pipeline. Incorporating security testing of the code (static and dynamic) as part of the CI/CD process is also part of this domain.
• Cloud Security Posture Management (CSPM) – We need to discover the risks and continuously monitor the threats to the cloud resources. CSPM provides the means to this visibility. To get this visibility across all the cloud and non-cloud environments, we need to collect logs and events across all layers or domains – identity and access, infrastructure, application, and data. A unified dashboard or console for centralized security management is a component of CSPM. This dashboard also integrates findings from other security tools on misconfigurations that can lead to security exposures. Through this dashboard, security focals can view the security posture of all the deployments. Security Orchestration, Automation, and Response (SOAR) extends CSPM by alerting critical incidents and orchestrating automated responses. CSPM also provides a way to proactively carry out vulnerability, configuration, and threat management through the analysis of the security data collected from all the other security domains.

A pattern-based approach to address hybrid cloud security

Patterns are successful solutions to a repeating problem. As we understood in the previous section, the security domain is vast and includes multiple dimensions. It is difficult to find the skills and talent that can rightly address security challenges efficiently across all these domains. It is also difficult to find experts, security architects, and engineers who are knowledgeable across all these security domains. Hence, the recommendation is to take a pattern-based approach to solve the challenge of how to implement hybrid cloud security.

A security pattern provides a reusable solution to a generally repeating problem and provides guidance on how to design, develop, implement, and operate it efficiently.

A sample security pattern template is discussed in the paragraphs that follow. This template definition follows the details defined by the Architectural Patterns work published by The Open Group (http://www.opengroup.org/public/arch/p4/patterns/patterns.htm).

We will use this template to capture the problem context and the solutions across various security domains.

The following is the sample pattern template:

• Name: A short name that captures the essence of the security problem and solution.
• Problem: Describes the problem context with more details on the issues to be solved and the objectives to be met. This captures the functional objectives or business goals to be met by the solution.
• Context: This captures the context for the problem to be solved. Includes the pre-conditions, forces, constraints, and qualities to be met by the solution. The forces, constraints, and qualities describe the non-functional requirements to be met. This includes but is not limited to aspects such as the ease of construction, reliability, performance, scalability, throughput, availability, correctness, effectiveness, resiliency, and serviceability.
• Solution: This describes the components that make up the solution and how they interact to deliver the intended goals. The solution or blueprint captures the static as well as the dynamic behavior of the solution including the systems, actors, and their collaborations. With a schematic diagram, the solution section details the various components and their interdependencies. The solution section also discusses the alternatives with relevant trade-offs and the rationale for deciding on a particular option versus another within a specific context. At a high level, it captures the post-conditions after the pattern is applied.
• Known uses: This section will share an example of how the pattern is applied and the resulting context. This will share how the pattern can be implemented with various cloud providers such as AWS, Google Cloud, Azure, and IBM Cloud.
• Related patterns: Patterns do not exist in isolation. Multiple patterns may need to be combined to resolve a complex problem. This section will also capture alternative patterns and a dependent predecessor, as well as successor patterns however applicable.
• Known uses: Known applications of the pattern within existing systems, verifying that the pattern does indeed describe a proven solution to a recurring problem. Known uses can also serve as examples.

The Open Group template has the forces as a separate section of the pattern template. To keep it simple, the forces, qualities, and constraints applicable to a scenario are captured as part of the context section in this book. This book includes the patterns across the various security domains and groups them under the following categories, listed as follows:

• IAM patterns
• Infrastructure security patterns
• Data security patterns
• Application security patterns
• DevSecOps patterns
• Cloud security posture management and response patterns
• Zero-trust patterns

Summary

We have discussed the what and why of hybrid cloud security in these first two chapters. Now, we need to know the difficult part of how to achieve hybrid cloud security. That is what the remaining chapters of this book will focus on.

In the next chapter, we will learn about the IAM domain further and the patterns to implement authentication, access control, and auditing for the cloud.