Cloud Security: 5 Lessons I Learned the Hard Way

This blog was originally published by OpsCompass here

Written by John Grange, OpsCompass

It’s 2021, and it’s clear that cloud is a global IT trend relevant to every company, regardless of size or industry. The main cloud infrastructure providers (AWS, Azure, and GCP), as well as their local alternatives (Alibaba Cloud, for example), deliver hundreds of services that are purpose-built to make it easy for developers to set up and configure.

According to the providers themselves, the range of cloud services is robust, pricing models are mostly clear, and cloud platforms are designed to build and operate systems securely. But does this mean that we no longer need cloud security engineers? No! Despite all the efforts cloud providers take to secure services by default, enterprises with complex needs must ensure the cloud works for them and that can be a big challenge…

In this post, I’ll discuss five surprising security lessons that I learned the hard way while managing and operating applications in the cloud.

1. Do Not Allow the Cloud to Become a Jungle

Robust service offerings? Hundreds of images available in the marketplace? Spinning new services with only a few lines of code? Cloud makes this possible, and it’s exactly what you need to deliver high-quality solutions quickly! But, not long after the initial novelty wears off, you’ll likely realize that you have no clue about basic aspects of your environment such as how many servers you have in the cloud, what operating systems they’re running, or what their hardening status is. What’s more, your accounting team will want to know why there is a five-digit bill for 100 new servers (for example) that someone created in the cloud.

Governance isn’t the sexiest topic, but if you don’t think about it from the very beginning, your cloud infrastructure will become a jungle—with all kinds of services, operating systems, and configurations running on it. And, after a few years without governance, it will be easier for you to build another infrastructure from scratch than to bring what currently exists to the desired state.

On a positive note, AWS, Azure, and GCP all have a robust set of tools that allow you to introduce security guardrails around available services and track which configurations are running on specific services. The options are there; you just need to configure the tools and make sure they cannot be easily bypassed.

2. Check Twice Before Making Anything Public

One great thing about the cloud is that it allows you to make systems or data accessible to your users with a few clicks of the mouse or several lines of code. Unfortunately, there is a price to pay for that convenience: If, for some reason, you misconfigure your servers or storage services, your data will be available to everyone on the Internet. Even worse, careless administrators may expose your development environments with default passwords. This allows attackers to get an initial foothold on your infrastructure and launch more sophisticated attacks against other systems in your company.

Obviously, cloud providers will warn you about insecure configurations, but this is simply not enough to stop the many security incidents that happen every year. That’s why security engineers should stay constantly informed about any storage services or systems your company exposes publicly.

3. There Is Such a Thing as Too Much Security

As soon as you start exploring the robustness of the security services your cloud provider offers, you will be amazed by how many audit trails, logs, and metadata you can collect. After happily enabling all of them, you will soon learn that the amount of information you are being flooded with is simply indigestible.

Similar to traditional systems and infrastructures, the most important thing here is to understand what’s normal for your environment. Once you understand that, you’ll be able to analyze your logs to look for suspicious events that are likely to be malicious. You should also consider introducing some cloud-native configuration state monitoring tools, which can complement your log analysis program. Otherwise, you will spend precious time scrolling through thousands of irrelevant security events—and you’ll miss the ones that are symptoms of a real attack. Note that the average time to detect an attack in 2020 was 220 days, so there is still huge room for improvement!

4. Avoid Reinventing the Wheel

Let’s say you have a custom tool, or process, that you utilize for managing and protecting your traditional infrastructure, and you want to apply it to your cloud infrastructure. Please, don’t! The reason is simple: the cloud infrastructure paradigm is very different from that of the traditional data center. How? Well, for starters, the fact that in the cloud the security perimeter is IAM, whereas in the data center it was the corporate network is quite profound, and secondly, there are hundreds of services all with APIs and they’re evolving all of the time and it’s up to you to keep up.

As a result, you will need to constantly update and improve your custom tools to stay up-to-speed on the latest services as well as ensure you’ve got a handle on IAM across your cloud environment – no small task. This will be a never-ending story—and, in the end, your tools will still have less features than native-cloud options or commercial tools that are continuously developed to meet the needs of companies relying on cloud infrastructure.

Summing up, avoid reinventing the wheel—unless your company has a team of software engineers who want to create a differentiating cloud monitoring tool. Otherwise, you will end up with frustrated system owners who cannot understand why half of their infrastructure is not monitored or why their monitoring service is down after AWS (or whichever provider they’re working with) changed their naming convention.

5. Think About Compliance Before Starting Your Cloud Journey

Yes, AWS, Azure, and GCP have all published comprehensive documentation and referenced long lists of standards and regulatory requirements that they are compliant with. But, if you haven’t considered the shared responsibility model, which demarcates the responsibilities of the cloud service providers and their customers, now’s the time.

First of all, although cloud provider’s infrastructure is compliant with certain regulations, the solutions you build on top of it may not be. For example, let’s say your cloud provider offers a set of capabilities across their data services that can be used to meet GDPR requirements around encryption. It’s still your responsibility to correctly configure these capabilities when you build your infrastructure and deploy your app..

Moreover, there are certain countries and industries that still do not allow you to take full advantage of the cloud services of your choice. For example, Russian regulations have strict limitations on where you can store and process personal data of Russian citizens. Finally, remember this possibility: In some cases, only a subset of available cloud services will be compliant with the regulation of your choice.

For these reasons, I strongly suggest that you take a close look at your cloud provider’s shared responsibility model before beginning your cloud journey. Also, make sure you understand your regulator’s position on cloud services before you start building solutions on top of them. Otherwise, you may need to bring down services shortly after you deploy them.

Summary

In this post, I discussed five key things I’ve learned about cloud security along the way. But this is just the beginning, as cloud services are complex and ever-evolving in their depth and breadth. Does this mean that cloud security is ultimately more difficult to manage than the security of traditional systems? Not really; it’s just different.

Remember that your cloud will be as secure as you decide to make it, thanks to the many native security services offered by cloud providers, as well as commercial tools currently available on the market.

A substantial component of successful cloud security is having the right culture. The way you ultimately avoid the pitfalls I laid out here is to have a cloud security culture that embraces openness, agility, flexibility, automation, and collaboration with other stakeholders. It’s difficult at first but when you get it right the sky is the limit.

About the Author

John Grange is a seasoned entrepreneur, co-founder and Chief Technology Officer of OpsCompass. John is a member of various national cloud security and technology committees and organizations, such as Forbes Technology Council and Cloud Security Alliance (CSA). He is a technologies expert with over 15 years of experience building products and companies, including co-founding Managed.com, a top-five global Microsoft ASP.net hosting provider and creating SaaS products across diverse industries and verticals such as healthcare (Layered Health) and marketing tech (Layeredi). John’s passion is identifying mega trends that leverage new technology and building new innovative products to create business value for customers.