Good or bad, the cloud adoption represents a new pathway for anyone to become a software startup without having to hire operations or infrastructure personnel. Although they can quickly get a minimally viable application up and running, that application may lack both robustness and security measures of more traditional, well-engineered systems. I’m pretty sure that none of these people wanted to leak all of their data across the internet. They were implementing systems to the best of their capabilities and constraints at the time. These errors appear to be symptoms of pursuing goals while under limitations of resources, and this may be where the solutions may lie.
The industry faced an analogous situation years ago when the theft and loss of backup tapes and laptops was primary cause of data breach.1 After fruitless years of trying to restrict human behavior, we redesigned our systems and simply encrypted data at rest on portable devices. This has driven physical loss of confidential data to below 10 percent as a cause of breach. Not only did we use technology to lessen a very predictable human problem, we also increased tolerance of failure. A single lapse, such as leaving a laptop in a car to be stolen, does not mean that an entire organization’s data has been compromised. We need the same level of failure tolerance with access controls and IT security in the cloud.
A good place to start to fix this would be better education and more accurate mental models of cloud computing, not just at the operator level but also at the managerial level. If one were to believe the hype about the cloud, then they would believe it is easily and quickly implemented with very little risk beyond moving your applications. The reality is that in the cloud, all of your infrastructure is virtualized and runs as software. Services and servers are not fixed but can shrink, grow, appear, disappear, and transform in the blink of an eye. How cloud services function is different than on-prem services. For example, AWS S3 buckets have characteristics of both file shares and web servers, but they are something else entirely. Practices change as well: You don’t patch cloud servers; you replace them with the new software versions. There is a difference between the credentials used by an operational instance, like a virtual computer, and credentials that are accessible by that instance, like the services it can call. Cloud computing requires a distinct way of thinking about IT infrastructure.
Cloud Robustness Through Diversity
Those doing well with both cloud security and operational efficiency have embraced a diversity model. A recent study by the Cyentia Institute examined cloud security versus on-prem with some interesting findings.2 Organizations, both large and small, have more problems with cloud security than middle-sized organizations with annual revenues between $1M and ~$5B. Organizations adopting hybrid cloud also do much better with security -- those that use four different cloud providers have one-quarter the security exposure rate. Organizations with eight clouds have one-eighth the exposure. Both data points could speak to cloud maturity, operational competence, and the ability to manage complexity. Compare this to the “lift and shift” cloud strategies, which result in over-provisioned deployments and expensive exercises in wastefulness.3
The Big Picture
Given all of this, how do you put a cloud defense strategy together? You begin with the chosen cloud deployment model, as we discussed in part 1. Here’s a summary with key threats and defenses highlighted.
Software-as-a-Service (SAAS) Cloud
This is an application service delivered by the cloud. Most of the infrastructure is managed by the provider. Examples of SaaS include Office 365, Dropbox, Gmail, Adobe Creative Cloud, Google G Suite, DocuSign, and Shopify. Here you are only responsible for your logins and your data. The primary threats are against those logins from things like phishing, credential stuffing, and stolen credentials. Controls include MFA, ser management processes, application config hardening, and data-at-rest encryption (if available).
Platform-as-a-Service (PaaS) Cloud
This is a platform to build applications into delivered by the cloud. The provider manages the platform infrastructure, but you build and run the applications. Examples of PaaS include AWS S3 buckets, Azure SQL Database, Force.com, OpenShift, and Heroku. Here you are only responsible for your logins and your data. In addition to the threats targeting SaaS deployment models (access attacks), you also need to concern yourself with securing the application itself against web app attacks. In this model, you are likely to have exposed APIs and services interfaces that could leak data if not locked down tight. Controls include User/Role Rights Management processes, secure API gateways, Web App Security, Web App Firewalls, bot scrapers, and all the controls needed for SaaS.
Infrastructure-as-a-Service (IaaS) Cloud
This is a platform to build virtual machine, networks, and other computing infrastructure. The provider manages the infrastructure below the operating system, and you build and run everything from the machine and network up. Examples of IaaS include AWS EC2, Linode, Rackspace, Microsoft Azure, and Google Compute Engine. Here you are responsible for the operating systems, networking, servers, as well as everything in the PaaS and SaaS models. In addition to the threats targeting SaaS and PaaS models, a primary security problem here is exploited software vulnerabilities in your OS and infrastructure as well as network attacks. Therefore, you will need to harden your virtualized servers, networks, and services infrastructure. You’ll need all the aforementioned controls in addition to strong patching and system hardening, and network security controls.
On-Premises (On-Prem) / Not Cloud
This is the traditional server in a rack, whether it’s in a room in your building or in a colocation (Colo) facility. You’re responsible for pretty much everything, including sticking the big metal rectangles into the racks and plugging the wires in. If you’re in a colo, you don’t have to worry too much about physical security, power, and HVAC. However, you will now be concerned with network connectivity and reliability, as well as resource management. In addition to threats to your networks, physical location, and hardware itself, you’ll need to secure everything else mentioned above.
The Big Picture
Here’s how all of these models come together in a single diagram showing the varying attack surfaces you need to consider for each cloud model. Figure 1 combines the highlights of the above descriptions.
Of course, if you have a hybrid cloud deployment, you’ll have to mix and match these threats and defenses. In that case, a new challenge is unifying your security strategy without having to monitor and configure different controls in different models in different environments.
Security Secrets of the Cloud-Native
To wrap things up, here’s some of the things cloud natives have learned not only to keep themselves safe, but also to manage costs and maximize effectiveness. As with anything in technology and security, the strategy and priority decisions should come before the technological reasons. Don’t go to the cloud just to say you are going to the cloud. A desired goal and accompanying strategy will drive the plan and make apparent where deeper training and tooling are needed. We’ve written extensively on how to approach your cloud security plan as well as how to assess the readiness of the IT security team for cloud. Here are some specific organizational proficiencies that we feel are key to reduce the chance of a cloud breach:
Technical Skills and Strategy
- Strong understanding of cloud technology, including its deployment models, advantages, and disadvantages at the IT executive/management level
- Deep understanding of the operating modes and limitations of the controls provided by cloud platforms chosen
- Service Portfolio management including tracking of your environment, applications, deployed platforms, and ongoing IT projects
- Risk assessment and threat modeling including understanding the possible breach impacts and failure modes for each key service
Access Control Processes
- Defined access and identity roles for users, services, servers, and networks
- Defined processes to correct erroneous, obsolete, duplicate, or excessive user and role permissions
- Method for setting and changing access control rules across all data storage elements, services, and applications
- Method for automated lockdown of access to all APIs, logins, interfaces, file transfer nodes as they are provisioned
- Centralized and standardized management of secrets for encryption and authentication
- Defined and monitored single-path-to-production pipeline
- Inventory of all cloud service objects, data elements, and control rules
- Configuration drift detection / change control auditing
- Detailed logging and anomaly detection
Adherence to secure standards
- Guardrails to ensure secure standards are chosen by default including pre-security certified libraries, frameworks, environments, configurations
- Audit remediation and hybrid cloud governance tools
- Automated remediation (or deletion) of non-compliant instances and accounts
- Automated configuration of new instances that includes secure hardening to latest standard