They say every cloud comes with some gray. That sentiment stands equally true for virtual clouds as it does for physical ones. A recent survey by Forrester saw 93% of respondents claiming their company is mostly on the cloud. Yet, another study by ZScaler claims that 98.6% of companies have misconfigurations in their cloud environment.
This isn’t surprising, because cloud is a relatively recent technology and there are always growing pains when it comes to adopting something new. But attackers are always on the prowl for any kind of vulnerabilities, and your cloud teething woes fall under their scope.
The fallout once they gain access ranges from “could’ve been much worse” to “as bad as it gets”. The former sentiment was seen with Toyota last year, when they revealed that over 2.6 lac customers’ data was exposed due to a misconfigured cloud environment. A seemingly innocuous cloud setting gave hackers access to 8 years’ worth of in-vehicle device ID and map data. Yet, the breach was low-key enough for Toyota to not get any flak for their handling of cloud environments.
The same can’t be said for Capital One, where a misconfiguration led to the PIIs of over 100 million Americans and 6 million Canadians being leaked, with an estimated business loss of $200 million. That’s pretty much “as bad as it gets”, and it’s important to be cognizant of the fact that your organization could also be regarded as a cautionary tale if you don’t get your ‘cloud house’ in order.
The good thing is misconfigurations are avoidable if the team in charge of your cloud operations is well trained. It’s essentially a human error, yet a widespread one. Gartner says that until 2025, up to 99% of cloud environment failures will be attributed to human errors, but with enough stringent processes, it’s easy to be part of the 1%.
How do we put these processes in place?
It’s important to begin with defining exactly what cloud misconfigurations are. Any bugs, gaps or errors that could expose your data to risk during cloud adoption, migration and setup come under the purview of a ‘cloud misconfiguration’.
What makes these vulnerabilities so widespread are the complexities of multi-cloud settings combined with the difficulties associated with manually identifying and correcting these errors. Misconfigurations occur when permissions, settings or access controls are not properly set or are left at default values, creating unintended security gaps. Like most security vulnerabilities, the fallout can lead to breaches that result in loss of trust and business.
At the root of the cloud misconfiguration problem is inadequate change control. Whenever there are insufficient processes for managing changes to your cloud systems, applications, or infrastructure, you leave yourself open to vulnerabilities and service disruptions.
Now, if you’re already on the cloud, chances are you’re using one of AWS, Azure or GCP. All three are different but are dogged with the same misconfiguration issues. Thankfully for us, each issue does have simplistic, succinct solutions.
Access Management
What’s the problem?
People often confuse ‘authenticated’ users with ‘authorized’ users and give access to the former that they shouldn’t be possessing. A common misconfiguration in AWS is to allow access to your S3 bucket to all AWS users instead of just the authorized users.
Many development teams also create default credentials to simplify the developmental process – credentials that are too easy to guess and known to many.
What are the solutions?
- Ensure that your role policies follow the principle of least privilege, so you can assign them specific & limited permissions.
- Impose phishing-resistant MFA for all users.
Serverless Realities
What’s the problem?
A major concern about cloud is the fact that your data is no longer in your domain. For example, AWS has a Lambda environment that lets you instantly run code for any type of application without provisioning and managing servers. The problem lies in these functions being accessible globally.
Another such instance comes from your cloud applications being linked to hosting services that are susceptible to vulnerabilities. HTTP not triggering towards HTTPS is one such example.
What are the solutions?
- Your cloud functions should be configured to be publicly inaccessible, a particular necessity when you’re operating in multi-cloud environments.
- Taking the proper due diligence and monitoring measures to ensure your hosting web service is not vulnerable.
- Following best practices & configurations prescribed by your third-party vendors for their components and services.
Virtual Environment
What is the problem?
VMs have become an integral reason for what makes the cloud so transformative. Unfortunately, configurations like no limits in your VM instances and keeping custom ports enabled can have serious ramifications that wipe out the massive benefits they bring.
What are the solutions?
- Set a limit on the number of VMs you can create, and ensure only administrators have access to them.
- Restrict your open ports to essential systems, especially when you’re migrating to a multi-cloud architecture. Monitoring them is an absolute must once you complete the migration.
Networking
What is the problem?
When you’re on the cloud, it’s important to realize you’re directly or indirectly connected to many other networks. IP forwarding is a way cloud environments use this reality to their benefit, an instance where an OS accepts incoming network packets not meant for their system, only to pass it on to another network. While it can streamline processes, it can also definitely create data security risks. Public IP enabled on your VMs is another such example.
What are the solutions?
- Ensure all your security groups have IP forwarding disabled.
- Limit provisions of public IP addresses for resources.
Databases
What is the problem?
Ground realities show that SSL certificates aren’t being rotated whenever a certificate expires or new/modified constraints need to be imported. Moreover, misconfigurations leave many databases accessible to the public.
What are the solutions?
- Always enforce SSL certificate rotation on database services
- Always ensure your databases aren’t accessible publicly.
Apart from these 5 elements, we’d like to share another key piece of advice that people often neglect: settings & configurations suitable for your development environment aren’t appropriate for your production environment. For example, allowing incoming requests at any rate from any server may seem fine in development, but can lead to major problems in production. Apps hosted on cloud must move to production environments only after conducting vulnerability assessments and pen-testing.
We’d like to leave you with this: fool proofing yourself from these common misconfigurations is only the first step to creating a secure cloud environment. Monitoring and tweaking your approach to new advances both in cloud and the approaches of the attacker can help you stay ahead of the curve.
Thankfully, iValue helps with all of it, so partner with us today to be on ‘Cloud 9’ when it comes to managing misconfigurations!
