Back in the day, the theft and loss of backup tapes and laptops were a primary cause of data breaches.

That all changed when systems were redesigned and data at rest was encrypted on portable devices.

Not only did we use technology to mitigate a predictable human problem, we also increased the tolerance of failure.

A single lapse, such as leaving a laptop in a car, doesn’t have to compromise an organisation’s data. We need the same level of failure tolerance, with access controls and IT security, in the cloud.

In the cloud, all infrastructure is virtualised and runs as software. Services and servers are not fixed but can shrink, grow, appear, disappear, and transform in the blink of an eye. Cloud services aren’t the same as those anchored on-premises.  For example, AWS S3 buckets have characteristics of both file shares and web servers, but they are something else entirely.

Practices differ too. You don’t patch cloud servers – they are replaced with the new software versions. There is also a distinction between the credentials used by an operational instance (like a virtual computer), and those that are accessible by that instance (the services it can call).

Cloud computing requires a distinct way of thinking about IT infrastructure.

A recent study by the Cyentia Institute shows that organisations using four different cloud providers have one-quarter the security exposure rate. Organisations 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.

So how do you determine your optimal cloud defense strategy?

Before choosing your deployment model, it is important to note that there isn’t one definitive type of cloud out there.

The National Institute of Standards and Technology's (NIST) definition of cloud computing lists three cloud service models infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS)). It also lists four deployment models: private, community, public, and hybrid.

Here’s a quick summary of how it all works through a security lens:

·Software-as-a-Service (SAAS) cloud is an application service delivered by the cloud. Most of the infrastructure is managed by the provider. Examples include Office 365, Dropbox, Gmail, Adobe Creative Cloud, Google G Suite, DocuSign, and Shopify. Here, you are only responsible for your logins and data. Primary threats include phishing, credential stuffing, and credential theft. These can be controlled via solutions such as multi-factor authentication, application configuration hardening, and data-at-rest encryption (if available).

·Platform-as-a-Service (PaaS) cloud is a platform to build applications into before they are delivered by the cloud. The provider manages the platform infrastructure, but you build and run the applications. Examples include AWS S3 buckets, Azure SQL Database, Force.com, OpenShift, and Heroku. You are only responsible for your logins and data. In addition to SaaS threats (access attacks), there is a need to secure the application itself against web app attacks. In this model, you are likely to have exposed APIs and service interfaces that could leak data if unsecure. Controls include User/Role Rights Management processes, secure API gateways, Web App Security, Web App Firewalls, bot scrapers, and all the referenced SaaS controls.

·Infrastructure-as-a-Service (IaaS) Cloud is a platform to build virtual machines, networks, and other computing infrastructures. The provider manages the infrastructure below the operating system, and you build and run everything from the machine and network up. Examples include AWS EC2, Linode, Rackspace, Microsoft Azure, and Google Compute Engine. 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, the main security concerns are exploited software vulnerabilities in OS and infrastructure, as well as network attacks. This calls for a hardening of virtualised servers, networks, and services infrastructure. You’ll need all the above-mentioned controls, plus strong patching and system hardening, and network security controls.

·On-Premises/Not Cloud 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. There’s less worries about physical security, power, and HVAC but there are concerns related to network connectivity and reliability, as well as resource management. In addition to threats to networks, physical location, and hardware, you’ll have to secure everything else mentioned above.

If you have a hybrid cloud deployment, you’ll have to mix and match these threats and defenses. In that case, an additional challenge is to unify your security strategy without having to monitor and configure different controls, in different models and in different environments. Other, specific organisational proficiencies integral to reducing the chances of a cloud breach include:

• Technical skills and strategy
  • A strong understanding of cloud technology, including its deployment models, advantages, and disadvantages at the IT executive/management level.
  • A deep understanding of the operating modes and limitations of associated controls.
  • Comprehensive service portfolio management, including tracking environment, applications, deployed platforms, and ongoing IT projects.
  • Risk assessments and threat modelling, including understanding 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.
  • Methods for setting and changing access control rules across all data storage elements, services, and applications.
  • Automated lockdown of access to all APIs, logins, interfaces, and file transfer nodes as they are provisioned.
  • Centralized and standardized management of secrets for encryption and authentication.

• Observability
  • 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 and 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.

Any strategy and priority decisions should come before the technological reasons. Don’t go to the cloud for the sake of it. A desired goal and robust accompanying strategy will show the way and illuminate where deeper training and tooling are needed.