For twelve years I’ve held executive management positions at companies making significant use of the cloud. Now I have the privilege of helping lead Fugue, a leading provider of cloud security and compliance solutions. Along the way I’ve found that senior executives—both at technology companies and outside the tech industry—sometimes struggle to understand the security implications of moving to the cloud. It’s common for executives to simply make blanket declarations that the cloud will never be secure enough for them (untrue), or alternatively to hold the belief that the cloud service providers like Amazon, Microsoft and Google take care of all the security issues for you (also untrue).

Here then are five key points you actually need to know about the security implications when you are considering moving more of your data and applications to the cloud. Some of these points are not intuitively obvious. The good news is that if you get things right your cloud infrastructure can be even more secure than your datacenter.

1. Absolutely Everything is Software Defined

The first thing to understand about the cloud is fairly self-evident, but it takes a while to fully absorb the implications. Absolutely everything in the cloud—servers, databases, the network, even security—is defined through software, specifically via Application Programming Interfaces (APIs) defined by the cloud providers. This provides tremendous flexibility, agility and power — including the power to know the state of all infrastructure at any point in time. However it also means there is great risk and potential vulnerabilities stemming from what are effectively software errors—misconfiguration of the resources that make up the cloud infrastructure.

Infrastructure misconfigurations are by far the largest source of cloud data breaches. Hence security and compliance in the cloud is all about ensuring the configurations defined through software are correct. As a best practice, ensure your teams are defining and automating cloud infrastructure configuration through “infrastructure-as-code” tools and techniques, versus manual or ad hoc approaches.

One common misconception about the cloud is that the cloud providers take care of all security requirements. This is simply not true—each provider has some version of what is referred to as a “shared responsibility model” for security. Basically this means everything you can define through their software APIs is your responsibility to secure, while the security of physical datacenters and physical infrastructure is theirs. Another way to think about this is to consider the cloud itself to be secured by the cloud service provider, while what you put in the cloud is for you to secure.

2. Your Developers Are Likely in Control of Cloud Security Policies

Given that cloud infrastructure is defined through software, it often falls to the developers to specify it. For them, the ‘infrastructure-as-code” becomes one more code artifact for them to manage as part of their project. The danger here is that in addition to the compute and storage resources required by the application this can include critical network and security configurations. If you are not careful you could have your developers defining cloud security policies by default.

Regardless of how your teams are organized you want to ensure that staff with sufficient expertise in information security and network design are involved in reviewing infrastructure configurations. As a best practice, ensure that infrastructure compliance and security checks are incorporated early into the software development lifecycle as part of a “shift left” security strategy. Automate these checks and incorporate them into the CI/CD (continuous integration/continuous deployment) methodology and toolset that your developers use to develop, test and deploy software. You should also look at separating out critical security and network infrastructure definitions from the compute and storage resources required by applications—and have these under the control of staff with direct responsibility for cloud infrastructure.

3. Traditional Datacenter Security Techniques and Tools Don’t Transfer to the Cloud

In the datacenter world, the approach to security has generally been to secure the “perimeter” and the endpoints, and assume this is mostly enough to keep the enterprise tolerably secure. In the cloud, there really is no perimeter (if there ever was one) and so the strategy and tools used in the datacenter simply don’t carry over. In the datacenter we use a firewall to secure our perimeter and restrict the traffic that passes through. In the cloud, instead of a firewall we have security group rules that define what network traffic to let through to the protected private networks we establish. However, our first and best line of defense is via identity and access management (“IAM”)—you may even hear people saying “identity is the new firewall”. Security group rules, network definitions and identity and access management are all configured through the cloud provider APIs, as with all other cloud infrastructure. It’s critical to get these configurations right and ensure they stay that way.

Another important difference in the cloud is that security teams do not have direct access to network traffic to monitor for intrusions. This is something the cloud provider does as part of the shared responsibility model. If you are early in your transition to major cloud adoption you may find your security team struggling to understand how to secure your cloud footprint. To help mitigate the skills and knowledge gap look to hire cloud expertise into the security team. You may want to consider taking some of your developers who have been working on pilot or early cloud projects and making them cloud security engineers.

4. You Need Automation (The Bad Guys Certainly Have It!)

Bad actors are constantly scanning the Internet looking for cloud infrastructure misconfigurations to exploit. If the bad guys are using automation then you need automation to stay ahead by finding vulnerabilities and quickly fixing them. The industry calls this “automated remediation”.

As AWS CISO Stephen Schmidt pointed out at the recent AWS re:Inforce security conference in Boston, manual remediation methods are simply too slow. Consider the amount of time it takes—once you’ve found a vulnerability in your cloud configuration—to create a ticket, get it assigned to an engineer and then have them fix it. Hours or even days could go by before the issue is fixed. We call this “Time To Remediation”, and your “Mean Time to Remediation” (MTTR) needs to be in the order of minutes, not hours and days.

Another reason Stephen discussed for moving to automated remediation methods is the limited availability of qualified security engineers. There simply aren’t enough to keep all our cloud infrastructure secure using manual methods.

In the past security automation has had a bad rap because of automation gone wrong—downtime events caused by security bots and other automation that inadvertently brings down production systems. Security teams need to overcome their understandable aversion to automation, because the risks of potential harm are great and automation is the only solution.

As a best practice look for cloud security tooling that provides true automated remediation “out of the box”. Otherwise your engineers will have to write lots of tedious and error-prone code that without the right context can mess things up.

5. Your Cloud Infrastructure Can Be More Secure Than Your Datacenter—If You Get Things Right

It’s true: if you get things right, your cloud infrastructure really can be more secure than your datacenter ever was. If you are still worried about putting sensitive data and critical applications in the cloud this may seem counter-intuitive, but consider the following.

First off it’s almost certain that the physical datacenters run by Amazon, Microsoft and Google are more secure and more reliably operated than datacenters you operate yourself. Their sheer scale, resources and ability to replicate sophisticated processes across a very large fleet of datacenters are now unmatched. And they attract and retain the best talent in fields like datacenter operations, network management and security engineering.

Secondly, in the datacenter world excessive reliance and trust in the perimeter defense model resulted in insufficient hardening of resources behind the firewall. With the cloud by necessity you need to move to a “zero trust” model, spending more time ensuring all infrastructure is secure, and all workloads are hardened.

Finally, because everything in the cloud is software defined it is possible to fully automate security and compliance—the asset inventory and full details of how things are configured is available through cloud provider APIs. With the right tools you can use automation to make your infrastructure secure, and then keep it that way on a continuous basis.

Hopefully this gives you some pointers on what you need to think about as you consider the security implications of greater cloud adoption in your organization. 

While You’re Here…

If you’re operating at scale in the cloud and care about the security and compliance of your cloud infrastructure environments, Fugue can help. With Fugue, you can:

1. Validate compliance for your cloud environments against a number of policy frameworks like CIS, HIPAA, PCI, SOC 2, NIST 800-53, ISO 27001, and GDPR.
2. Get complete visibility into your cloud environments and configurations with cloud infrastructure baselining and drift detection.
3. Protect against cloud infrastructure misconfiguration, security incidents, and compliance violations with self-healing infrastructure.
4. Shift Left on cloud infrastructure security and compliance with CI/CD integration to help your developers move fast and safely.
5. Get continuous compliance visibility and reporting across your entire enterprise cloud footprint.

Schedule a free cloud security workshop or compliance audit to get a handle on your cloud security posture and learn how Fugue can help.