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.
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.
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.
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.