Cloud computing has revolutionized the IT world, making it easier for companies to deploy infrastructure and applications and deliver their services. The idea of not having to spend millions of dollars on equipment and facilities to host an on-premises data center is a very attractive prospect.
Besides, resources in the cloud must be safer…right?
Wrong. I often hear this myth from customers, but the truth of the matter is, without common sense security practices, proper configuration, and the right skillsets administering the cloud presence, cloud services are just as vulnerable, if not more so.
The Shared Responsibility Model
The reason for this is the shared responsibility model of cloud services, where the responsibility for security is divided between the customer and the provider. Customers often overlook this, and poor assumptions are made about the security of their cloud-based resources.
The cloud service provider is responsible for the virtual and physical security of the cloud infrastructure. The customer is responsible for their own data, the security of their workloads, and any internal networks within their virtual private cloud.
Another important aspect is access control. This is really no different than it has been in the past, except the physical security of the data center is handled by the provider. The customer is still responsible for locking down access to its own resources and data.
What does this mean for cloud customers in a practical sense? Let’s take a look at some common security issues that can arise in the cloud.
Misconfigured Amazon S3 Buckets
Amazon S3 is a truly great service from Amazon Web Services. It allows customers to store data, host static sites and create storage for applications among other things.
At the same time, misconfigurations in S3 buckets can make them a prime target for malicious actors.
One such instance occurred in 2017 when Booz Allen Hamilton, a defense contractor for the United States, was pillaged of battlefield imagery as well as administrator credentials to sensitive systems. In another 2017 incident, the records of 198 million American voters were exposed. Chances are, yours were included.
Most incidents involving S3 are a result of poor configuration, not a hacker breaking in using sophisticated techniques. But with so many organizations using Amazon S3 to store uploaded data from customers for processing by other applications, there is a real possibility of more sophisticated attacks.
Loose API gateways
APIs are great. They allow you to interact with programs and services in a programmatic and automated way. They are a cornerstone of all cloud services, allowing the different services to communicate.
As with anything in this world, this also opens a world of danger.
API gateways were designed to be integrated into applications. They were not designed for security. Untrusted connections can enter the gateway and retrieve sensitive data. API requests to the gateway can come with malicious payloads. DDOS attacks are another common problem.
Using the right configuration is a key way to prevent API attacks. DDOS attacks at the API gateway can be throttled by limiting the number of requests for each method. Denying anonymous access is critical. Changing tokens, passwords and keys limits the chance that stolen credentials will be effective. Disabling any type of clear-text authentication, enforcing SSL/TLS encryption and implementing multi-factor authentication are also great deterrents.
Migrating Uncorrected Compute Resources
One common method of migrating from an on-premises datacenter to the cloud is the “lift-and-shift” approach. This means customers take the virtual machines running in their datacenter and simply migrate those to the cloud.
But what kind of security assessment was done on those virtual machines prior to migrating? Were the machines patched? Were security flaws fixed? The answer is often no — which means the customer is simply moving problems from one location to the next.
A better way to migrate to the cloud is ‘correct-and-lift-and-shift.’ The most important thing to remember is that these are computers. They are still vulnerable to malware, so regardless of being in the cloud, the same security controls are required including things like anti-malware, host IPS, integrity monitoring and application control.
Free Range Virtual Networks
Cloud services make it incredibly easy to deploy networks and divide them into subnets and even allow cross network communication. They also provide the ability to lock down the types of traffic that are allowed to traverse those networks.
This is where security groups come in. Security groups are configured by people, so there’s always that chance a port is open that shouldn’t be, opening a potential vulnerability. It’s incredibly important to really have a grasp on what a compute resource is talking to and why, so the proper security measures can be applied.
So is the cloud really safe from hackers? It’s no safer than anything else, unless organizations make sure they’re taking security in their hands and understand where their responsibility begins and the cloud service provider’s ends.
The arms war between hackers and security professionals is still the same as it ever was—the battleground just changed location.