I’m often asked what the biggest cyberthreats are in the cloud. When people pose that question, they seem to be expecting an answer on par with a Hollywood movie plot. The truth is far simpler.
The number one threat in the cloud today is service misconfigurations.
Despite the cloud’s clear operating model, teams continue to make simple mistakes or overlook the simple task of properly configuring the services they use in the cloud.
How Does Security Work in The Cloud?
Security in the cloud works using the Shared Responsibility Model. This model dictates who is responsible for any operational task in the cloud and security is simply a subset of those tasks.
The model itself is simple.
There are six areas where daily work is required. Starting with the physical (is the building holding the systems safe, paid for, etc.) moving through infrastructure, virtualization, operating systems, applications, and data.
In a traditional on-premises environment, your organization is responsible for all six areas. That work is usually divided up among several teams, but at the end of the day they all report into one person within the organization, typically the CIO.
When you move to the cloud, at least half of your responsibilities are delegated to your cloud provider.
In infrastructure (IaaS) level services like instances or virtual machines, you take over at the operating system level. The configuration and maintenance of the OS is entirely on you and your team.
So if you want to set your Administrator or root password to password you can. Don’t. But you could, it’s your responsibility.
As you move towards more abstract or SaaS-type services, your responsibilities decrease. This means that you can focus on fewer areas in order to improve your security posture.
Trust But Verify
Any security professional worth their salt won’t simply take the cloud service providers word that they are fulfilling their responsibilities under the model, nor should they.
This is where compliance attestation comes into play. The big three cloud providers all have an overwhelming amount of audit evidence showing how they provide world class security.
From the hyper-local compliance frameworks to broadly applicable ones like PCI-DSS or SOC1 or ISO 27001, any concern about the cloud service providers’ side of this model should be alleviated.
Taking things a step further, you can always request a copy of the audit results from your provider for a specific compliance framework. In fact, you’ll need that report for your compliance report when the time comes.
Where Do Misconfigurations Come From?
Circling back to the main cloud threat of misconfigurations, they bubble up from two separate places. The first is misunderstanding of who is responsible for an area of responsibility.
In these scenarios, teams building in the cloud are expecting their provider to build controls and monitor for specific issues when in fact these areas are the responsibility of the team.
A sadly common example of this is when teams are using virtual machines or instances in the cloud with a pre-configured deployment service. In these cases, the cloud provider has simplified the steps required to get common configurations up and running in the cloud.
That’s great, but the gap is that once the configuration is up and running, it’s the responsibility of the team building the solution to patch, harden, and maintain that configuration.
Just because your provider has given you a lead out of the gate doesn’t mean you don’t have to run the rest of the race!
The second area where misconfigurations come from are simple mistakes. The cloud is an amplifier for teams. With one API call you can launch the equivalent of an entire data centre. The downside is that smaller teams are responsible for a wider variety of tech stacks and services.
Inevitably, teams make simple mistakes that lead to unnecessary exposures. One crucial way to address this is by embracing the software principle “systems over people.”
Systems Over People
This principle is a simple one. Most of the work for your cloud solutions should be done by systems and not people. Automation is key to success here.
Let’s say the operating system your team uses for your systems has a new patch that needs to be deployed. Instead of someone patching each of the production virtual machines, that team member should patch the original template of the virtual machines and a build system should redeploy production.
In fact, team members shouldn’t even have the ability to log in to production servers. Production should be as stable as possible and managed only by the systems you put in place.
This will reduce errors overall and the errors that do come into play are consistent and easier to address.
Security is a Quality Problem
Understanding the Shared Responsibility Model is critical to success in the cloud. While complex, sci-fi-type threats are fun to imagine, there is a very real challenge around misconfigurations today.
In addition to understanding the model, treating service configuration like another set of software tests will catch these misconfigurations before they hit product. Using automation tools or a configuration management tool provided by a cloud provider will help ensure that you’re taking full advantage of the features that your provider has built to help you secure your use of these services.
By embracing the principle of systems over people and having a set of automations that cover your responsibilities in the cloud you can have a strong security posture in the cloud while enabling business teams to move quickly.
The post The Shared Responsibility Model appeared first on .