When engineers are thinking about vulnerabilities in the cloud, a lot of the typical concerns are MFA, DDoS attacks, data leaks, and API access. Although these concerns are top tier, many organizations are thinking about them once they've already happened or they're trying to solve the specific problem. Instead, engineering leadership should think about the problems before they have the opportunity to arise.

The issues that lead to those big vulnerabilities are typically a predecessor to more fundamental problems due to the ease of use in the cloud.

In this blog post, you'll learn about the top 3 cloud vulnerabilities which are the typical reasons why big security and vulnerability risks occur.

The User Interface

One of the biggest issues that typically lead to vulnerabilities is the user interface in many public cloud platforms. Why? Because it's easy to click through and navigate. There have been countless amount of times that someone who isn't knowledgeable in the cloud space logs into the UI, clicks next a few times, and spins up a server. That server ends up being open to the world, has a public IP address, and has a default password.

Although the cloud and the UI have made many implementations easier, it's also opened up some of the largest vulnerabilities in cloud computing history.

The other huge concern in many public cloud UI's is that all of the default settings, which allow engineers to just click right through and complete the process, are typically settings that are 100% open. The server isn't locked down at all, it has a default network set up, no IAM roles/rules are associated, and many other large security risks.

Open Networks

When you think about traditional networks (routers, switches, firewalls, etc.), you used to have to manually SSH into the network appliances, configure the settings, save the settings, and then exit the terminal session. That workflow allowed engineers to truly think and see what they were doing, which typically meant they could think twice before finishing the configuration. With the cloud, the workflow is completely different.

Although you can (and absolutely should) set up proper networking in the cloud, you don't really have to. It's extremely easy to set up a security group (which is essentially a firewall), open all ports, allow all IP addresses, and connect that security group to a cloud service. Typically, a lot of beginner-level cloud engineers will do this so they can get an application/service working, not thinking of the consequences.

The consequences are that any cloud service associated with the security group is now open to the entire world from a networking perspective. It's an open field day for attackers.

Stateful and Stateless Data

Data is data. Every engineer has worked with it in one way or another, whether it be databases, code, files, folders, etc.. The traditional method was to have some file server, a SAN, or a NAS storing the data. Those traditional methods would then be backed up, scaled, and high availability would be the default. In the cloud, it's a bit different.

When thinking about data in the cloud, engineers typically rely on cloud services like AWS S3, AWS RDS, Azure Storage, and many other services. Although those services have amazing uptime numbers, nothing is definite. The cloud is just a bunch of servers, and servers fail. Because of that, you have to think about how to scale your data, back it up, and ensure it's always available.

If AWS S3 had some sort of DDoS attack and your data wasn't available, would your company be able to continue its work for the day? How about if the same thing happened to RDS?

Regardless of if data is in the cloud, you still must bring the engineering thought process back to as if it was still on-prem. Backups, scalability, high availability, and many other factors come into play. The likelihood of data in the cloud not being available is most likely less than if you were running a few servers in a data center rack you rented, but it's still 100% possible, so you should be prepared.