The Top Worry In Cloud Security for 2021
The cloud is an environment full of potential, providing easy access to technologies that weren’t available a decade ago. However, its not always as sunny as it seems. Continue on to read about the top worry in cloud security for the upcoming year.
The cloud is an environment full of potential. It provides easy access to technologies that simple weren’t available a decade ago.
You can now launch the equivalent of an entire data centre with a single command. Scaling to meet the demands of millions of customers can be entirely automated. Advanced machine learning analysis is as simple as one API call.
This has allowed teams to speed up innovation and focus almost exclusively on delivering business value.
But it’s not all unicorns and rainbows. The assumption was that alongside this increase potential, the security challenges we see on-premises would be grow as well. Teams should be struggling with zero-days, vulnerability chains, and shadow IT.
It turns out they aren’t.
At least those issues are nowhere near the top of their list of concerns. The top security challenge for builders in the cloud is very straightforward.
Their biggest challenge is making mistakes in the form of service misconfigurations.
Shared Responsibility
Now I know at least a few of you have raised your eyebrows at that statement. And I will back it up in a minute.
But first, let’s look at the evidence around the initial assumption that people make about cloud security. They assume the cloud service providers themselves are a big risk.
The data doesn’t support this at all.
Each of the big four cloud service providers Alibaba Cloud, AWS, Google Cloud, and Microsoft Azure have had two security breaches in their services over the past five years…combined.
Now, before we get into each of these, it’s important to note that each of the big four have had to deal with tonnes of security vulnerabilities over this timeframe.
A large number of cloud services are simply managed service offerings of popular commercial or open source projects. These projects have had various security issues that the providers have had to a deal with.
The advantage for us as users, as builders, is how operations works in the cloud. All operational work—and make no mistake, security is operational work—done in any cloud follows the Shared Responsibility Model.
It’s very straight forward.
There are a six primary areas where daily operational work is required. Depending the type of service you are using in the cloud, your responsibilities shift.
If you’re using instances or virtual machines, you are responsible for the operating system, the applications running on that OS, and your data.
As you move to an entirely managed service, you are only responsible for the data you process and store with the service.
For all types of cloud services, you are responsible for service configuration.
Despite having a clear line of responsibilities, the providers offer a number of features to help your meet your responsibilities and adjust the services to suit your needs.
Cloud Service Provider Issues
Now, looking back at the two provider security issues over the past five years…
The first one we’ll look at is from March 2020.
In this case, Google Cloud paid out a $100,000 reward through their bug bounty programme to a security researcher who found a privilege escalation issue in Google Cloud Shell.
This is a service that provides a browser-based interface to the command line of a virtual machine running in your account. Under the covers, this shell is simple a container running an application to provide the required access.
The researcher noticed that they were able to use a socket connection in the container to compromise the host machine and escalate their access.
The root cause? A misconfiguration in the access to that socket.
The second example is from January 2020 and it involved a service offered in Microsoft Azure.
Here an issue was reported in the Microsoft App Service offering.
This vulnerability allowed an attacker to escape the expected boundaries of the service and access a limited-scope deployment server with elevated privileges.
The reason? A misconfiguration in the open source tool used to provide this web app hosting service.
In both cases, the vulnerabilities were responsibly disclosed and quickly fixed. Neither issues lead to any reported customer impacts. Both of these cases were in higher level cloud services.
These are services that the provider’s teams built using other services on the platform. As a result and inline with the shared responsibility model, they were at risk of a service misconfiguration.
Even the hyperscale providers face this challenge!
3rd Party Validation
There’s more evidence to support that fact that misconfigurations are biggest issue in cloud security.
Security researchers in the community that study clouds issue have all published finding that align with this premise. Whether from other security vendors or industry organisations, the findings agree:
65-70% of all security issues in the cloud start with a misconfiguration.
Making it worse, 45% of organisations believe that privacy and security challenges are a barrier to cloud adoption. Why is that worse?
When understood, the shared responsibility model makes it easier to maintain a strong security posture. Organisations should be pushing to move faster to the cloud in order to improve their security!
Direct evidence
But surveys and targeted research projects only go so far. What does the publicly available evidence say?
Here’s a list of some of the most visible cloud security breaches in recent years;
- MCA, 500,000 loan documents
- RNC, 187,000,000 voter records
- THSuite, 30,000 cannabis dispensary records
- Booz Allen Hamilton, ??? top secret records
- Dow Jones, 2,200,000 customer records
- WWE, 2,000,000+ customer records
- Verizon Wireless, 6,000,000 customer records
- Accenture, 40,000 infrastructure passwords & details
- Capital One, 100,000,000 customer records
- US DoD, 1,800,000,000 data records for analysis
- Alteryx, 120,000,000 personal records
- CAM4, 10,000,000 personal records
If you filter out all the reports of cloud hacks and breaches to remove incidents that were not cloud specific—so those where the issue wasn’t related to cloud, the service just happened to be there—over two billion sensitive records have been exposed through a breach in cloud security.
Let’s take this further and remove every single breach that wasn’t due to a single misconfiguration.
Yes, single. One wrong setting. One incorrect permission. One simple mistake…caused all of these breaches.
That leaves the Capital One breach.
This more complicated event was caused by …two misconfigurations and a bug. An in-depth analysis of this breach shows that the bug was inconsequential to the overall impact which was 100 million customer records being exposed.
What’s more is that Capital One is a very mature cloud user.
They are a reference customer for AWS, they’ve been a huge advocate of cloud within the community, and were the incubator for the very popular open source security, governance, and management tool, Cloud Custodian.
This is a team that knows what they are doing. And yet, they still made a mistake.
Pace of Change
That’s really what misconfigurations are. They are mistakes.
Sometimes those mistakes are oversights, other times an incorrect choice made due to a lack of awareness. It all comes back to the power made accessible by the cloud. Reducing these barriers has had a commensurate increase in the pace of innovation.
Teams are moving faster.
As these teams mature, they are able to maintain a high rate of innovation with a low failure rate. In fact, 43% of teams who have adopted a DevOps philosophy are able to deploy at least once a week while maintaining a failure rate of under 15%.
Critically, when they do encounter a failure, they are able to resolve it within the day…more impressively 46% of those teams resolve those issues within the hour. But, as we know, cybercriminals don’t need a day. Any opening can be enough to gain a foothold creating an incident.
What about teams that aren’t at this pace?
Well the other 57% of teams, the majority of which are large enterprises, often feel that their lack of pace provides protection. Moving cautiously in the cloud allows them to take a more measured approach and reduce their error rates.
While this may be true—and there’s no evidence to support or disprove this assumption—change is still happening around them.
The cloud service providers themselves are moving at a rapid pace.
In 2020, the big four hyperscale providers released over 5,000 new features for their services.
For single cloud users, that means almost 2 new features a day…at a minimum. For the growing set of multi-cloud users, the pace of change only increases.
So even if your team is moving slowly, the ground underneath them is shifting rapidly.
Goal of cybersecurity
Now the goal of cybersecurity is actually quite simple.
The goal is to ensure that whatever is built works as intended and only as intended.
In a traditional on-premises environment, this standard approach is a strong perimeter and deep visibility across the enterprise. That doesn’t work in the cloud.
The pace of change is too rapid, both internally and with the provider. Smaller teams are building more and more. Quite often, by design, these teams act outside of the central CIO infrastructure.
This requires that security is treated as another aspect of building well. It cannot be treated like a stand alone activity. This sounds like a monumental task, but it’s not.
It starts with two key questions;
- What else can this do?
- Are you sure?
This container running the code that creates the financial reports. What else can it do? Can it access other types of data? Are you even sure it’s the right container?
This is where security controls provide the most value.
Top pain points to address
Most of the time when we talk about security controls, we talk about what they stop.
Using an intrusion prevention system can stop worms and other types of network attacks. Anti-malware controls can stop ransomware, cryptominers, and other malicious behaviours.
For every security control, we have a list of things it stops. This is excellent and works well with subject matter experts…a/k/a the security team.
Builders have a different perspective. Builders want to build. When framed in the proper context, it’s easy to show how security controls can help them build better.
Posture management helps ensure that settings stay set regardless of how many times a team deploys during the week. Network controls assure teams that only valid traffic ever reaches their code. Container admission control makes sure that the right container is deployed at the right time.
Security controls do so much more than just stop things from happening. They provide answers to critical questions that builders are starting to ask.
“What else can this do?”. Very little thanks to these security controls.
“Are you sure?” Yes. I have these controls in place to make sure.
When built well and deployed intelligently, security controls help teams deliver solutions that are more dependable, easier to observe, and more reliable.
Security helps you build better.