Cloud Security Series - Part 1: Cloud Security Fundamentals

Cloud Security Fundamentals

While the cloud in general is getting more and more adopted, good cloud security implementations are still a rarity. Many companies bring legacy security approaches from the on-premises world into the cloud. Old processes and obsolete frameworks. Other companies ignore security entirely. Not out of malice but simply because cloud security can be more complex than initially thought. The results are similar: Wasted cloud potential, frustrated project teams and risky, unstable environments. If we truly want to leverage the cloud as it was intended to be leveraged, with speed, flexibility and nearly unlimited potential, we have to take cloud security more seriously.

In this two-part blog series, I will guide you through the overall cloud security fundamentals. Fundamentals that might be familiar to some, if not most, and experiences I gained through my years as a cloud consultant and cloud security professional. Let’s start with the fundamentals.

Get the Fundamentals Right

When dealing with the cloud, systems are no longer running in on-premises environments protected by outer walls. They are no longer isolated from the rest of the world but are part of a large ecosystem that is interconnected and accessible from around the globe. That means we can no longer keep people out by simply shutting ourselves off. We could try, but that would just take away all the benefits the cloud has to offer. Flexibility, speed, scalability. And this is a hard pill to swallow: We cannot make our cloud fully safe by isolating it. Isolation has its place, but it won’t work on its own. Never has, never will. But what do we do instead? One word: Fundamentals.

Before we start with anything else in the cloud, we have to get the security fundamentals right. These fundamentals are not a nice-to-have. They are the foundation of everything that comes after. Without those, our cloud environment can never truly be secure. They are not magic, and they are not necessarily new or revolutionary. But that doesn’t discount their value.

Shared Responsibility

Shared Responsibility is one of those expressions that gets thrown around a lot but is crucial to understand when you move into the cloud. There are parts of the cloud the cloud provider is responsible for, and then there are parts you are responsible for. And that line is usually pretty strictly defined. AWS, for example, takes care that no one breaks into their data centers at night to steal their hard drives. That is not your problem to worry about. But whether or not you encrypt the data in your cloud database and make the database publicly accessible in AWS? Well, that is on you to decide and handle. And the sooner you get familiar with what is yours to take care of, the easier the process of setting up your cloud security will become. Make sure you know what you are responsible for in the cloud.

Zero Trust

Like I said before, the cloud is a huge interconnected ecosystem. It’s like a big city, while your on-premises data center is more like your local village. And while it might be possible to know and trust all the residents in a small village, it’s impossible to know and trust all residents in a big city. There are just too many moving pieces. But how do you know whom to trust in such an environment? Easy. By default, you trust no one. You wouldn’t let a stranger into your apartment, would you? That’s what Zero Trust means. There is no inherent trust in the cloud. No matter who talks to each other, they always have to establish a trust relationship first. And it does not matter where they are located or how often they have an exchange. Assume no one can be trusted by default. Always validate who someone is and what they want. Implement trust boundaries and enforce continuous authentication. And only once you’ve verified who they are and you’ve established trust, can you proceed.

Least Privilege

Least Privilege and Zero Trust go hand in hand. Making sure someone is trustworthy is of little to no use if you do not control what they are allowed to do once the trust relationship has been established. Let’s go back to our apartment analogy. Zero Trust ensures only trusted people are allowed to come in. Enforcing Least Privilege is making sure they don’t go through your fridge uninvited. It means to only assign permissions that are needed to the entities that need them. Gone are the times of default administrator access. If you only need read permissions on a certain database once a month, you should only get read permissions on this database once a month. This takes time and due diligence, but will be worth it in the end. Handing out administrator access for free might sound faster on paper, but you will come to regret it once an attacker infiltrates your cloud environment. Make sure you only assign the permissions needed.

Lessons from the Field

While these fundamentals are certainly important and the foundation of every secure cloud setup, they are not the whole picture. There is a lot more to consider when making your cloud environment secure and protected. That’s what I would like to talk about now.

In this last part, I would like to highlight a few things I learned along the way. Personal opinions that were formed by evaluating cloud environments and looking at enterprise security efforts over the years. It is not set in stone, and it shouldn’t be. It is meant to spark ideas and open discussions. It is also not meant to be a comprehensive list. Security is ever evolving and new ideas and ways to go about things pop up all the time. The three topics below are just the ones that I find worth talking about when securing cloud environments.

Replace Gates with Guardrails

I said it before and I will say it again. Security through isolation alone will not work in the cloud. You can try to lock every door there is but you will realize there will always be another door. It’s like chasing clouds. You will exhaust yourself, drain your team’s resources, and in the end achieve little. You might even make matters worse. Because security should enable business, not hinder it. And when you lock every door there is, you might keep the bad guys out, but you will also lock your own people inside. Well then let’s open every door there is, you might say. But that is no solution either. There is more than the extremes. But what is the alternative?

First of all, you have to let go of the notion you could achieve complete security. That has never been possible and never will be. Second, you have to accept that your job as a security professional is to guide and enable. Sure, you need to block and prevent, but in a granular, subtle and continuous way that doesn’t cripple your business. Traditional security used to say ‘No.’ Modern cloud security asks, ‘How?’. It enables by setting boundaries and letting project teams freely move within these boundaries. You don’t ban services, you define policies on how to use them. You don’t dictate workflows, you define what should be part of a secure workflow and let the project team model their own within the boundaries you defined. You set the standard. You clearly define what is acceptable and what is not. You don’t dictate outcome, you dictate behavior. And you enforce it without compromise. But as long as teams are honoring your boundaries? You let them move. You give them the one thing they value above all else: agency. And they will reward you with the two main beneficiaries of agency: innovation and progress. And while letting them loose is scary and uncomfortable at first, in the cloud, where everything is trimmed to be fast, flexible and adaptable, there is no other way. Start to guide. Define and enforce boundaries. And trust your teams.

Baked-in Security Automation

If you have come this far, you probably realize that the cloud is a big ecosystem. And most cloud environments grow rapidly once the adoption has been accepted by the internal teams. And while I already said that you should let go of the notion of control and define boundaries in which your teams can roam, I also said you should enforce your boundaries. Because boundaries that cannot be enforced are just requests. But how do you enforce boundaries in such a rapidly growing environment? Manually checking and approving each cloud deployment before it goes into production? Good luck.

No, we do it through automation. Teams leverage the cloud to build cloud-native, event-driven architectures in the cloud. Why shouldn’t we do the same when it comes to security? We need to automate detection and remediation wherever possible. We define boundaries and should detect automatically if those boundaries are crossed. And then we should automatically enforce those boundaries. Services like AWS Config are the perfect example for this. Automatically detect when resources deviate from your defined baseline and trigger automated workflows to remediate the resource. If you do not focus on automation in your security endeavors, you will have a hard time keeping up with the ever-growing environments and you will be overwhelmed. And in the beginning, you might enforce a boundary too strictly or not strictly enough. And that is completely fine. It’s not about being perfect. It’s about trying to get better every day. So, automate detection and remediation of security issues and boundaries wherever possible.

Shift-Left

Security automation as described above is often treating a symptom but not the root cause. Still important, don’t get me wrong, but not the complete picture either. Treating symptoms is important to keep the whole system from collapsing, but you still have to find and remove the root cause to fully heal. And that is what Shift-Left embodies. It means dealing with an issue before it can even become an issue by looking and dealing with it a few steps earlier. This is scalable and efficient. You offer secure baselines and security checks before infrastructure is even deployed.

Hardened images are a perfect example. You define what acceptable images should look like, and then you provide your teams with hardened images and enforcing their use. These images already conform with the boundaries and guardrails you defined. Enforcing the use of Infrastructure as Code and Infrastructure as Code checks using Policy as Code is another example. If you want everything to be encrypted all the time, why waste time searching every resource that is not encrypted? Instead, define a secure baseline and enforce it before resources are deployed. And if a team tries to deploy something that isn’t encrypted? Well, your automated security checks won’t let them. Shift-left and deal with the issues at the core. Security needs to be built in and not added later.

Turning Lessons into Action

Cloud security can be a bit overwhelming when you have never looked at it in its entirety before. And that is fine. Like I said before, it’s not about being perfect right away, but about trying to improve all the time.

When you start putting the ideas I highlighted in this blog post into action, I am certain that you will be able to drastically improve your own security landscape.

I hope this blog provided useful insights and practical ways to improve your own cloud setup and overall security posture.

— Hendrik

Title Photo by Scott Blake on Unsplash