8 Most Common Cloud Misconfigurations to Look Out For

Recently, Amazon accidentally exposed information on Amazon Prime Video viewing habits to the public. In addition, Thomson Reuters news and media company admitted that their servers had compromised 3TB of data by public-facing ElasticSearch databases. Well, these are the type of news we often see on the front page of cybersecurity forums. But if you dig a bit deeper, you will find that these data leaks are caused by misconfiguration, not cyber attacks. 

From 2017 to 2021, misconfiguration has risen to 5th place in the top web application security risks list. High usage of cloud services is one of the major reasons for this increase since there is a high margin for human error when cloud services are configured. For example, misconfigured cloud services can cause cyber exposures, security breaches, insider threats, application downtime, and information leakages, ultimately hurting organizations’ reputations.

So, in this article, we discuss eight of the most common cloud misconfigurations you need to look for to increase security in your cloud infrastructure.

The Impact of Cloud Misconfiguration

Cloud misconfiguration is one of the most common security issues in applications. Even the NSA considers cloud misconfiguration one of the leading vulnerabilities in modern applications since it can expose your systems to external hackers, ransomware, malware, or insider threats.

These misconfigurations mostly occur due to the complexity of the cloud settings, and many developers find it hard to understand them properly. In fact, a Gartner study states that 80% of all data security breaches and that up to 99% of cloud environment failures would be traced back to humans making mistakes until 2025.

This is hard because there is no one-time fix for misconfigured cloud problems like leaks. But putting in place security measures when the infrastructure is being made would help. So, DevOps and security teams must work together to improve application security.

Cloud Security Challenges and How to Manage Them

Today, many organizations use various cloud services to fulfil nonfunctional requirements like on-demand scalability, high availability, and maintainability. Unfortunately, this creates an additional layer of complexity that makes it even more challenging for security teams to keep up with ongoing changes.

Cloud service providers like AWS and Google Cloud make a significant effort to ensure their services’ security. However, they follow a shared responsibility model, and users must also take necessary steps to protect their data and services from attackers.

Following security best practices is one of the easiest ways to address those difficulties. For example, you can:

• Evaluate security with methods like OWASP
• Only grant access for solid credentials
• Always provide the least access
• Encrypt data while it’s moving and sitting still
• Use technologies to find and stop intrusions
• Continuously audit and test for vulnerabilities

In addition, an automated cloud security posture management (CSPM) solution will let you know when your systems might be vulnerable, when resources are set up wrong, or when changes could be harmful.

8 Most Common Misconfiguration Types

1. Overly Permissive Access

When it comes to accessing cloud services, being too permissive might involve:

• Putting old protocols into use on the cloud host
• Allowing access to ports on the outside
• Putting sensitive APIs out in the open without the proper controls
• Creating ways for private and public resources to talk to each other

Policies that apply to specific workloads or cloud memberships make up the list of access controls. When setting up applications, giving too many permissions to access controls can provide attackers with a way to move up or sideways within the system and increase the attack surface.

2. Exposed Storage Access to External Actors

Another type of cloud configuration error is making storage assets available to people outside the cloud. Organizations often mistake “authenticated” users for “authorized” users and give access to the “authenticated” users by accident. These authenticated users may include any customer or user with proper credentials since they are verified by AWS but not by your institution or application.

This misconfiguration allows cyber attackers to access the storage and find important information such as passwords, API keys, and other login information. So, taking the necessary steps to prevent such incidents is essential. Essential data in storage buckets should be encrypted with strong encryption by default. Security teams should also keep an eye on all storage nodes that are marked as public and get rid of any permissions or access that are not needed.

3. Unrestricted Inbound and Outbound Ports

All ports that allow internet access to your resources could be a security risk. Therefore, the security team should know all the open ports and only allows access to a limited number of ports as required.

In addition, outbound ports also create security issues. For example, allowing RDP and SSH access to servers from public networks or even networks outside your virtual private network can cause serious security issues in your cloud resources.

Outbound traffic from application servers should be limited to only the most critical applications and servers. You should follow the concept of least privilege, and SSH should have limited access to outbound ports since application servers hardly ever need to talk to other remote servers on the network through SSH.

4. Unlimited Access to Non-HTTP and HTTPS Ports

It is always good to only unlock the ports you need and block the ones you don’t. Else you will have to increase the security of all the ports. However, maintaining and monitoring a large number of ports is not an easy task, and attackers will always find a way to access your resources. When opening a port to the internet, you need to ensure that the traffic is encrypted and only specific addresses can use them.

5. Lacking Strict Monitoring and Logging

Organizations that have been around long don’t always have strict and robust monitoring and logging systems. But, it is vital to keep track of what is happening on your cloud service and log it.

These logs can help with the following:

• Keeping an eye out for suspicious behavior and security holes
• Taking note of an employee’s illegal actions
• Having regular reports
• Figuring out if there are any other missteps or wrong settings

However, logs are only useful if they are constantly looked over so that the proper steps can be taken. Ensure you have enough records for every action that could lead to a security flaw. Set up automated and aimed alerts based on such log data so any breach or suspicious activity can be found and fixed before it causes a significant issue.

6. Default Credentials for Cloud Instances, Databases, and Other Services

Using a set of default credentials to access cloud services makes it easier for software teams to carry out development tasks. For instance, developers share a set of predetermined credentials for various cloud services, such as databases and instance pools.

Most of the time, these default credentials are easy to guess or are known by too many people. Even though it should be obvious, none of these credentials or configurations should be applied in production environments. Depending on the development environment, you should have separate configuration files.

It’s essential to set up a process to stop default credentials from spreading to the production environment and audit every release to ensure this process works. Ultimately, this will reduce the number of people aware of your infrastructure credentials.

7. Using Development Settings in Production Environments

Using the settings for development in a production environment is another common mistake. Although there might not be any issues in functionalities, there can be serious security issues since the configurations used in development environments are usually completely different from what we should use in production environments.

For example, letting requests come in from any server may seem fine during development. However, it can cause significant problems in the real world. This also includes code that is hidden in apps. For example, suppose sensitive debugging information is printed in the console. In that case, it could be missed and lead to a significant data leak in the production environment. Therefore, before launching to the production environment, you should carefully review these code settings and ensure they are correct.

8. Neglecting Third-Party Components

We use many third-party libraries, elements, and applications during the development process of an application. Some of these libraries might require access to your cloud resources. So it’s important to thoroughly research their security vulnerabilities before selecting third-party libraries. If there is a vulnerability in a library you use, attackers may use that vulnerability and access your resources.

Furthermore, some third-party libraries provide a set of best practices or recommend security precautions you need to follow. Following these best practices will reduce the threat of security breaches.

Keep calm and manage your secrets

With the increasing threat of cyber attacks, protecting API keys, passwords, encryption keys, and admin credentials has become essential. Not doing so is the equivalent of leaving your home’s keys taped to your front door. You can beat this by maintaining an inventory of company secrets in the cloud and regularly evaluating their security. Not managing your secrets properly helps threat actors to breach your systems easily, access your data, and overrun cloud resources to effect damage. 

Spectral can help you to beat this issue by automating the process of secret protection at build time. It monitors and detects API keys, tokens, credentials, security misconfigurations, and other threats in real time, enabling developers to ‘supercharge’ their CI/CD. Spectral also provides a variety of automated code security use cases, including infrastructure as code scanning, code tampering prevention, hardcoded secrets detection, source controls, CI/CD security, and source code leakage detection. To learn more, why not get free access now?