A behemoth of a topic and one that's incredibly divisive but, given limited time and resources, it’s important to focus on the key differentiators of ensuring cloud security.
Almost every company these days has a department dedicated to digital security thereby filling a key role in helping organizations protect their digital assets. As companies increasingly move and migrate processes and systems to the cloud, the role and importance of these departments inevitably grow. Tasked with compliance, information security, and data protection, information security professionals have a tough job of keeping up with the rapidly changing world of cloud computing.
There’s a reason that words like “info-sec review” and “IT security process” strike fear into the hearts of most software engineers and project managers alike. Particularly in larger organizations, these processes are often seemingly open ended, form-filling exercises rooted in legacy IT solutions and on-premise systems. Questions like “how many servers do you run?”, or “which version of this library are you using?” don’t make sense in the world of autoscaling, cloud-native services and CI/CD.
Cloud security is struggling to keep up with the rate of change and rate of adoption of cloud-native services. As engineers continue their march towards automating as much of their stack as possible, we should view cloud security with the same lens. Companies like Amazon have released a number of products and services to try and help with this, while making previously complex features like data encryption very simple to leverage.
Cloud security is a hugely complex area, but there are some steps you can take to make your journey easier. Start by encrypting everything - and treating all networks as untrusted, it’s a no regret move. Push hard to migrate away from any pet style virtual machines and towards commodity cattle. Lastly, automate everything else in your deployment process, so why not automate security too?
Anybody working in the cloud, or assessing cloud security needs to accept that the days of trusting security to network perimeters are gone. In on-premise systems, it’s common to find network security solutions that revolve around layers of trust. The internet is an untrusted zone and anything that goes there needs to be encrypted. You also might have a DMZ, where encryption rules might depend on data types. Lastly, on the “internal” network you might find a “trusted” zone, where the rules are significantly more lax --some communication is encrypted, others aren’t. Using self-signed certificates is acceptable, and data persistence is in plaintext.
The problem with applying this approach to encryption: What happens if an untrusted device is installed within the trusted network? The problem with applying this approach to the cloud is that infrastructure is shared, your attack surface is potentially much larger, and a small error in configuration can easily result in data loss. I’m going to defer to the expertise and wisdom of Amazon CTO Werner Vogels:
“Dance like nobody's watching. Encrypt like everyone is.”
Werner goes on to say that “Encryption is the tool we have to make sure that nobody else has access to your data. Make use of it”. It really couldn’t be any clearer than that, and it’s an important lesson to take heed of. Configuration mistakes will happen; with the move to faster releases and more frequent changes, it’s inevitable. Data breaches may occur and there are numerous and frequent examples of this from companies both large and small. The big difference is that if leaked data is encrypted, it’s still protected.
Encryption forms are an important last line of defense against a data breach, and it's a tough one to penetrate. Recent estimates suggest that even if using the Tianhe-2 supercomputer with 32,000 CPU cores and 48,000 GPU cores, it would take nearly 5.5 years to crack AES-256 encryption, the industry standard.
Previously, encrypting data was considered a difficult problem to solve, but in the cloud that’s no longer the case. AWS has built encryption into nearly all of its 165 cloud services, and in almost every case it can be enabled with a single mouse click or a single line of configuration. Certificates can be automatically managed and rotated using tools like Azure Certificate Manager,.And organizations wishing to control their own encryption keys can store them in a FIPS 140-2 compliant Cloud HSM (hardware security module) with native integration to most AWS services. In most cases, enabling basic encryption is free or even the default setting and thanks to hardware acceleration, the performance impact is no longer noticeable.
There’s no longer an excuse: encrypt everything, both at rest and in transit.
Don’t worry - we’re not suggesting for a moment that you should get rid of your furry (or not so furry) friends in the name of cloud security. We’re referring to carefully tended servers that are lovingly nurtured, and maybe even given their own names. Part of the operations team's job is to make sure that Mercury, Venus, Mars and more are well cared for, just like family pets. These are the machines that you log in to, patch, upgrade and nurse back to health when they fail. These servers are also an enormous security problem. Because somebody needs to look after these pets, somebody needs to retain root access to them. That somebody could make a mistake, lose their access credentials, or might even have their credentials compromised.
Cattle, on the other hand, aren't afforded quite the same love and attention as Mercury, Venus and Mars. In fact they're probably just referred to as “server-1” and “server-2” with tags applied just as you would to actual cattle. They’re all configured identically and immutably, and when one fails it automatically gets swapped out for another identical instance. These cattle instances are built automatically, using an automatic process that creates machine images. Instances are launched from these images. Nobody ever logs into them, because nobody is able to --services like SSH and RDP are disabled, and no credentials exist for remote login.
Migrating applications to cloud gives developers access to a huge range of new tools and technologies that make this transformation simpler. Infrastructure as code similar to Terraform and automation tools such as Ansible are some examples. Taking things even further, developers now have the option to move away from the virtual machine model and towards more cloud-native approaches, with containerization and serverless becoming incredibly popular. Because they move the operational and security responsibilities away from software development teams and towards cloud providers, containerization and serverless approaches maintain its popularity.
Developers are already automating more and more of their stack moving well beyond just scripted deployed and automated testing to fully automated infrastructure as code deployments. In this environment, with teams releasing changes daily or hourly, it’s hard to see how manual cloud security assessments can possibly keep up. Why not automate part of that security assessment as well?
A large number of vulnerabilities can now be easily detected using static analysis tools that inspect cloud environments and compare their configuration to publicized best practices and vulnerabilities. For example, virtual machines that have port 22 open suggest that SSH is enabled and accessible, or disks that don’t have encryption enabled would be in breach of the “encrypt everything” policy.
Of course there are a number of tools and approaches to help with automation including:
Cloud security is a hugely complex area and corporate information security teams tend to struggle to keep up with the pace of change in the cloud. As we’ve discussed, there are some concrete steps you can take to make your journey easier and to make your interactions with information security teams easier and less frequent.