Edgewise is now part of the Zscaler family. Learn More

The Impact of the Shared Responsibility Model on Your Cybersecurity Program

As the use of cloud computing has grown, so has the concept of the shared responsibility model for data protection and, more generally, cybersecurity. While not a new concept (we’ve shared security responsibilities with most outsourcing arrangements for many years), the nature of shared security responsibilities has changed with the advent of cloud. In a whitepaper, Microsoft makes it clear that they support shared responsibility in the cloud, but not all shared responsibility models are created equal. Microsoft explicitly states that defining data classification and protection controls are the responsibility of the customer, and then progresses down through the cloud computing stack, describing application and operating system controls, network capabilities, and the underlying host infrastructure that includes hypervisors, storage components, redundancy and scalability tools, and more.

Amazon Web Services follows a similar model. AWS breaks down the responsibility model into two primary categories: security in the cloud, and security of the cloud. Security in the cloud is the responsibility of the customer, and this includes data protection, identity and access management, OS configuration, network security (access controls), and encryption. AWS is responsible for the underlying pieces of the infrastructure, including the compute elements, storage infrastructure, databases, and networking. Most other cloud providers follow a similar model to Microsoft’s and Amazon’s. CenturyLink has a published shared responsibility model that also includes secure coding as one of their core responsibilities. Google does not have a public site or document describing its shared responsibility model for the Google Cloud Platform (GCP) formally, but they do have a document specifically outlining shared responsibility in their cloud for meeting PCI DSS compliance.

All cloud providers are wholly responsible for physical security of their data center environments. Cloud providers are also now responsible for data center disaster recovery planning, business continuity, and legal and personnel requirements that pertain to security of their operating environments. Cloud customers will still need to plan for their own disaster recovery and continuity processes, particularly in IaaS clouds where they’re building infrastructure. If backups of data in SaaS and PaaS environments are possible for cloud customers to manage, it’s recommended that these be incorporated into existing data protection and recovery strategies.

There are an enormous number of considerations for security teams that are integrating and leveraging the shared responsibility model with providers. These include some of the following changes and differences from traditional on-premises security operations.

Data protection and classification

For the most part, classifying data is always the customer’s responsibility, regardless of cloud model in use. There are a number of tools available from the different cloud providers’ platforms that can help label and/or identify certain data types and patterns, and these may help in applying data classification policies and effectively tracking the data. These include Amazon Macie and Microsoft Azure Rights Management, and are provided by the respective providers. That said, all responsibility for enabling, configuring, and operating these services lies with the consumer.

Data protection is a shared responsibility, and it’s dependent on the type of cloud in use. In SaaS environments, there may be some responsibility on the part of the provider to encrypt or restrict access to the data created or brought into the cloud environment. Similarly, PaaS environments may have some aspects of application development and operation that the provider maintains, while consumers also have more control over encryption, data masking, secrets management, and more. In IaaS environments like AWS, Azure, and GCP, encryption services are available alongside robust key storage and management tools that consumers can choose to employ. One responsibility all providers will assume is protection of cloud console user credentials, as these are stored within the provider infrastructure.

Endpoint and client protection

Client and endpoint protection are the responsibility of the consumer, except in SaaS environments where the responsibility is shared (for example, mobile device security for Microsoft InTune when accessing Office 365). One minor caveat is the assessment and security of system images offered directly from IaaS and PaaS providers; they will usually describe what steps they take to ensure all images offered are free of malware and are stable. Most configuration and patching responsibilities will still fall on the customer, however, as the provided images usually prioritize stability over up-to-date packages and OS kernels.

Identity and access management

With SaaS and PaaS offerings, identity and access management is shared, but is the responsibility of the customer entirely in IaaS environments. Most SaaS and PaaS offerings do not include any robust access controls, and many lack granularity in role and privilege policy creation and assignment, as well. In all major IaaS environments, identity directories can be created, and a policy syntax exists for creating privilege assignments to different cloud services and objects. None of this is managed by IaaS providers, though, so customers will need to create or integrate accounts and groups, and define policies to assign to each user.

Visit Edgewise at Black Hat, August 3-8, 2019 Booth #1612

Application protection and control

Naturally, application-level controls within SaaS offerings are secured by the providers entirely. This includes everything from software development lifecycles (SDLCs) to quality assurance and security testing and release. PaaS offerings are shared (all of the controls a SaaS provider would need to maintain are applicable, and many PaaS providers also offer secure code repositories and package management tools, which they configure and control). IaaS clouds require the customer to secure the application stacks they deploy. In the cloud, though, we may have some new and different options for application protection. First, some providers now offer robust services that may augment or replace application management tools traditionally installed on-premises. Security and development teams can then take advantage of code storage, orchestration, packaging, and other capabilities in an entirely cloud-native format. Second, security platforms like Web Application Firewalls (WAFs) are now available as cloud-native offerings from providers like AWS and others, which doesn’t change the responsibility of configuration and management (still the consumer’s responsibility) but does move the location of application security firewalling and management to a new location. The provider will of course be responsible for ensuring the service is functional and available.

Network security

In a SaaS environment, there is no networking to configure. Within PaaS cloud environments, some software-defined networking (SDN) may be configured for containers or similar services, and will be the responsibility of the customer. In IaaS clouds, network control is a shared responsibility. The provider operates the underlying SDN and tenants/consumers configure it within their cloud environments, including configuring their access controls, load balancing, routing, and connectivity. As switching is no longer available for configuration by tenants, all access control and segmentation will be applied via policies that (usually) only focus on layers 3 and 4 (IP addresses and ports) as well as tags or object references. Additional networking tools can be integrated to provide more granular microsegmentation, more capable routing, and intrusion detection.

Host-based security

Much like the network, the underlying compute stack is largely managed by providers entirely—only in IaaS environments will consumers have any access to or control over some of these capabilities. Some PaaS environments allow customers to create and manage container images and instances, as well. The entirety of host-based security controls and configuration will fall on customers—patching, hardening, antimalware, endpoint detection and response (EDR), and user management.

Virtualization security

In all current cloud environments, the responsibility for protecting every aspect of the virtualization infrastructure falls to the providers. This includes management platforms, virtual storage, virtual networking, and most importantly, the hypervisors. There are a number of threats facing virtual infrastructure, including virtual machine escape and side-channel attacks that focus on vulnerable drivers and shared infrastructure issues, respectively, and cloud customers will need some assurance from providers that these are mitigated through audit and control reporting.

Logging and Event Management

Generating logs in SaaS and PaaS clouds is somewhat hit-or-miss, but customers will have to download/export these logs themselves in almost all cases in order to integrate them into monitoring strategies. In IaaS clouds, customers can manage logging and monitoring entirely in the cloud itself, but often prefer to integrate with separate on-premises or additional service-based monitoring and analysis tools. The cloud providers will ideally maintain their own logs to track events within their operating environments, but the majority of responsibility for event management in every cloud type is the consumer’s.

One area that shared responsibility models rarely cover is security processes and workflows. For example, who is responsible for which aspects of incident response in the cloud?  Microsoft attempts to address this in another whitepaper that describes their concept of shared responsibility for incident response. It says that for any areas of customer responsibility (within a VM running in the Azure IaaS cloud, for example), Microsoft does not perform intrusion monitoring or incident response. For their own areas of responsibility, Microsoft details the roles and responsibilities of all team members and describes notifications and communications for each stage, then explains steps taken within the internal incident response teams.

Currently, most other providers offer little guidance related to security process responsibilities, which makes ownership a bit of a mystery until contracts are reviewed by the consumer. Optimally, more large providers will start to follow Microsoft’s lead and document all responsibility aspects of both security controls maintenance and security processes and workflows in the near future.

Dave Shackleford, Principal Consultant

Written by Dave Shackleford, Principal Consultant

Dave Shackleford is the owner and principal consultant of Voodoo Security and a SANS analyst, senior instructor, and course author. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering, and is a VMware vExpert with extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft, CTO for the Center for Internet Security, and as a security architect, analyst, and manager for several Fortune 500 companies. Dave is the author of the Sybex book Virtualization Security: Protecting Virtualized Environments, as well as the coauthor of Hands-On Information Security from Course Technology. Recently Dave coauthored the first published course on virtualization security for the SANS Institute. Dave currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance. Dave earned his MBA from Georgia State University.