The top challenge for your cloud security practice isn’t what you think
Is cloud security challenging? Yes.
Cybersecurity is challenging. Period.
So what are the unique issues facing a cloud security practice? And what do you need to know before you start planning out your practice?
Modernization required
As organizations adopt—or are born into—the cloud, traditional security practices are forced to change. The conventional methods of protecting assets and information just can’t keep up with the changes in processes and technology.
This point has been hashed and rehashed for years now. The tl:dr of it is that the sheer number of resources in any cloud environment, their rapid lifecycle, and the shared responsibility model for operations break traditional security approaches.
The baseline for security in the cloud is an approach that matches how organizations are using these environments.
Cloud adoption
It’s easy, even tempting, to oversimplify how organizations use the cloud. Even for companies that started in the cloud (typically newer startups) things are messy.
One cloud service provider (CSP) might offer most of what you need, but probably not everything and as a result, you’ll be dealing with multiple cloud services from multiple providers.
Ideally, you can keep that number low but there are just so many compelling services that the business advantages are quickly going to outweigh the complexity.
Unfortunately for organizations that have existing assets on-premises or spread out across multiple environments, things are even messier.
In order to help with these familiar challenges, the big three cloud CSPs all have published their version of a cloud adoption framework. AWS, Azure, and Google Cloud all offer the same guidance; migrate to the cloud project by project.
Why is this important and what does it have to do with cloud security?
It means that as your organization moves to the cloud, there will be an increasing number of projects all at different levels of cloud maturity.
Your cloud security practice needs to account for all of them.
Steps to maturity
Let’s look at how AWS summarizes these steps. They have an alliteration they call the “7 Rs.” Regardless of what you call them, the most common options moving to the cloud are;
- Retire
- Retain
- Relocate
- Repurchase
- Rehost
- Replatform
- Refactor
We can move the four simplest “Rs” right away.
Getting rid of a solution (retire) and keeping things as-is (retain) are very straightforward. Moving infrastructure from like-to-like (VMWare Cloud to VMWare Cloud or Kubernetes to Kubernetes) falls under relocate, and is again straightforward.
Buying something different (repurchasing) is a completely different process altogether. None of these “Rs” (retire, retain, relocate, and repurchase) impact your security practice in any way that’s unique to the cloud.
And the other categories? They need to be considered very carefully because rehost, replatform, and refactor are where the heavy lifting of cloud migration and evolution take place.
Steps one to three
If your organization has existing solutions running somewhere, the first step is to get them into the cloud (rehost). Your first instinct might be to start making changes to adjust to the cloud you’ve chosen.
Don’t.
The goal here is to take something that is working right now, and to make as few changes as possible in order to get it working in a new environment.
Sometimes called “lift and shift” or a “forklift”, this approach is often looked down on which is unfortunate because it’s the most logical approach to moving forward.
Once you have that solution working in your chosen cloud, now it’s time to make some changes (replatform).
Starting small, these changes can be as simple as creating automated deployment scripts. Or adding monitoring and observability telemetry to your environment.
Maybe it’s moving from a custom deployment of an open source tool to a managed version of the same. These small changes add up and reduce your overall operational burden.
Finally, as your cloud maturity grows, you start to redesign or refactor your solution.
Moving away from virtual machines to containers or even serverless functions. Breaking up your data storage into optimized services like NoSQL databases and simple object stores.
You refactor your solution to take advantage of what your cloud service provider has to offer. Ideally, this lets you scale up and down to meet customer demand and optimize your resources.
Of course, this takes time and effort. It’s a journey.
Many teams, many journeys
Pulling this back to cloud security, the problem—and yes, it’s a problem—is that your organization isn’t on one journey. Every team that’s building solutions is on its own journey…at its own pace.
This means your security practice needs to account for the beginners and the experts. You need to be able to support the teams forklifting existing workloads, including legacy workloads, in the cloud.
At the same time, you need to be able to support teams that are deploying to production multiple times per day.
Nothing illustrates this maturation of teams better than the annual “State of DevOps” report from DORA/Google Cloud. In 2016, the survey started grouping teams into performance categories. Those categories have evolved over the years.
Over the last six years, the top category has seen a huge expansion. So much so that a new category, elite performers, had to be created. Showing the effectiveness of the rapid iteration of the DevOps philosophy, 26% of all teams surveyed now meet the elite bar in the 2021 report.
While those teams are delivering value consistently with less risk, it’s the distribution of team maturity that is telling.
In the 2021 report (pg. 11), the team lists the following breakdown of team maturity;
- 26% are elite
- 40% are high performers
- 28% are medium
- 7% fall into the low performance category
Your security practice will have to account for and support teams at each of these levels.
Threats you have to deal with
Referencing another leader in the industry, the Cloud Security Alliance (CSA) has published the “Egregious Eleven.” This is a report that looks at the top threats to any cloud environment.
Understanding the variation in cloud maturity, we can view this report in a whole new light. The report not only explains the threat, but it also aligns the issue with security controls that can help mitigate the risk.
These controls are detailed in the CSA’s Cloud Controls Matrix. This matrix lays out various categories of controls that can help make sure that what you’re building does what you expect and only what you expect.
The top threat, data breaches, is broad and covers most of the basics of a security practice. It’s worth diving into, but a bit of an aside to the thread of this post.
Where things get interesting is when we analyze the remaining ten threats and align them with the concerns of teams at various levels of cloud maturity.
Risk prioritization
Working down the Egregious Eleven, there is a direct link between the threat and the areas that teams earlier in their cloud journey struggle with.
The State of DevOps reports and the Cloud Adoption Frameworks show an increase in automated systems, testing, and frequency of deployments as teams mature.
This approach has been proven over and over again to reduce risk by making smaller changes to production. It’s a lot easier to figure out what went wrong when there are one or two small changes to review vs. a massive batch of changes made during the previous month!
Number two on the Egregious Eleven is “Misconfiguration and Inadequate Change Control.” This is the hallmark of an immature cloud team.
Starting with the State of DevOps reports from 2014 and earlier, infrequent manual deployments and changes are the top roadblock for teams earlier in their cloud journey.
Misconfigurations are essentially mistakes. They happen. But they happen more often with manual and ad hoc processes. That’s not even a technology thing, that’s just people in general.
The Egregious Eleven is ordered by size of the threat. There is a correlation with the maturity of the teams building solutions in the cloud.
Focusing on everything at once
Your security practice needs to be able to address each of these threats in a manner that works for every team in your organization, regardless of their maturity level.
That’s a tall order. But it’s one that can be filled.
When you’re planning out and iterating on your security practice, you need to keep the complete picture in mind. The needs of a team that has just forklifted a legacy system into the cloud are very different from an elite performer that is deploying to production dozens of times per day.
These teams couldn’t be more different in their operation. Yet, they share the same goals.
They want to deliver resilient solutions to your customers. Their goals are the business goals. Your security practice needs to support that.
Any processes you create or tooling you roll out needs to support all levels of cloud maturity. You need to be able to adapt to teams that are just learning about concepts like autoscaling. At the same, you need to support teams that have gone completely serverless and are pushing the edge of what’s possible.
The first step? Understand these maturity levels and start to work through the Cloud Adoption Framework for your CSP. The output of that work is a business mapping that will help you identify the key stakeholders and teams.
You can use that to map their maturity level and start to discuss how your security practice can support their work in a manner that they will find helpful.
Categories
Suggested for you
