Organizations' migration to the cloud is a broad term that encompasses many different trends:
- Moving existing applications from private data centers to AWS, Azure, or the Google Cloud Platform as cloud service providers (CSPs), often referred to as lift-and-shift or infrastructure-as-a-service (IaaS).
- Completely restructuring how applications are built to make heavier use of prepackaged services available on these cloud service platforms – often referred to as lift-and-reshape, serverless, or platform-as-a-service (PaaS).
- Choosing to forgo running copies of standard applications instead of having the application vendor host them is sometimes referred to as drop-and-shop or software-as-a-service (SaaS).
Each of these three migrations exposes its security challenges:
Infrastructure-as-a-Service
At first glance, IaaS migration appears to introduce the least change. After all, the cloud is just your application running on someone else's computer. But CSPs supply you with that computer, along with an entirely new and unfamiliar management and control plane, a new identity and access paradigms, and new forms of storage.
The first generation of cloud-related breaches stemmed from organizations not understanding this new paradigm and placing confidential information in cloud storage while leaving access to the internet. This never happened to them on-premises, where their network firewalls and segmentation provided a backstop to this type of misconfiguration. What changed was there is no real way to physically surround all your assets in the cloud with a network and place firewalls at the edge of that network.
Unfortunately, internet-accessible storage is only symptomatic of the IaaS cloud being very different from your own data center setup. The August 2019 attack on AWS, which counted Capital One as its most visible target, provides a glimpse into the AWS management and control planes' complexity and the difficulty in getting all the security controls right. The presence of a simple vulnerability in a web application firewall (WAF), which could be exploited across the internet, led to large-scale leakage of confidential information across multiple AWS customers.
The crux of the issue is simple: CSPs provide incredibly complex ecosystems that are constantly in flux as new features are added. When adopting cloud services, security inherently becomes a shared responsibility model. This model falls to CSP customers to constantly adapt and deliver their half of the security operation that readjusts perfectly to the changing threat surface exposed by the CSP architecture.
Platform-as-a-Service
With PaaS, there are no illusions that everything is the same. But the security implications of adopting PaaS are not well-understood by customers either. The services in question range from simple (storage) to quite complex (analytics stacks). And each of these services has its own security idiosyncrasies. Want to use Amazon DynamoDB? Your engineering team must then understand how AWS identity and role-based access control (RBAC) intersect with DynamoDB. And they'll need to follow separate pages of security best practices – for preventive security, and other for detective security – and that's only for DynamoDB.
In addition to the adversity of securing services like DynamoDB, there is a bigger challenge with PaaS services: Security teams have no preexisting models that show how to secure a service embedded in an application without surrounding it with a secure network. There is no way to apply that model to PaaS-delivered services.
Also, note that the bias of CSPs is different from that of their customers. In rolling out new services, CSPs who develop those services are judged by adopting the service. When CSPs make decisions about the default security posture of a new service, they generally remove barriers to make customer deployments easier rather than add security controls, which might also slow down its adoption by customers.
Software-as-a-Service
SaaS has been broadly adopted as organizations realize that it allows them to bring up new applications overnight and never worry about software upgrades, backups, and other mundane support tasks.
But most SaaS applications provide little insight into network and security controls. Customers have some authority over who can access applications, permissions, data access, and – if you are lucky – an API that extracts access logs for validation. The security model of SaaS fundamentally hinges on identity and access. However, SaaS applications have become incredibly complex to configure.
Attempts to understand and secure all aspects of Office 365 or Salesforce would challenge most mortals. And keep in mind this is just part of a much bigger job for IT organizations tasked with provisioning access and overseeing security issues for applications. As more organizations leverage multiple SaaS applications, the onboarding and offboarding of employee access to SaaS applications become quite cumbersome. In some cases, employees have access to applications long after they leave.
Many organizations turn to identity providers and federation solutions between different SaaS applications to automate this task, often using a cloud-based HR system as the master database. Unfortunately, it only takes one compromised SaaS application or accounts for an attacker to gain full access to other federated applications and servers. This provides attackers with an excellent starting point for further lateral movement.
In addition, when an end-user is successfully phished, or a mistake is made in configuring some part of the shared-responsibility cloud model, there is no secure network acting as a safety net.
