How Serious of an Issue is a Misconfigured Cloud Server?

Cloud systems have become a built-in feature for nearly every business on the planet. Files aren't confined to one location, teams can access records from anywhere, and new services can be deployed quickly, which is remarkably convenient.

But using the cloud alone does not do anything by default to secure data. Even the most robust and complicated systems can be easily converted into a large security issue by even one small misconfiguration.

Even more, an attacker may not need to operate in a complicated manner in such a scenario.

You Don't Always Need to "Break" the System

Consider customer documents stored in the cloud folder of a company. Access to these files should be limited to specific employees.

However, if you inadvertently make the folder public and someone discovers this link they can access its contents. No passwords were cracked. No firewalls were breached. No malware was deployed.

The root cause is just a misconfigured access setting.

This is one of the more common examples that come up when cloud misconfiguration comes into play. However, this is not just the risk of leaving files exposed.

You Are Only as Good As the Access You Grant

Take the example of an employee who only needs to view reports. Nonetheless, their account may have been given the ability to delete files, add users and change system settings.

The employee does not intend to cause harm. However, they could inadvertently delete a key file or, if their account were hacked, an attacker would have a far broader sweep of the system.

Think of it like a hotel key. So if a guest goes to open their room and is able to access each and every single room in the hotel with that key, then the problem isn't that the key "works"; it's that it opens other doors too. Thus, in a cloud setting, each user should have only the permissions required for their role.

Why do we neglect test environments?

When a company builds a new application, they typically set up a test environment isolated from live production. While that type of system doesn't sound as if it is using real customer data, it may in fact be connected to your production system or using real customer data.

When a project is finished, if we do not decommission the test environment, then it stays active and exposed to the internet.

In addition, the security controls for test systems are sometimes weaker as well; simpler passwords may be implemented, logging could be disabled, and access restrictions can be less stringent.

Attackers often target these less-monitored peripheral systems instead of going after the main system directly.

Is Relying on Default Settings Enough?

Cloud services with pre-configured modes are available for quicker deployment. These default settings are helpful, but not every feature is necessary or appropriate for every organization.

A setting that's turned on by default doesn't guarantee it's secure. Areas such as access permissions, external connectivity, logging, and administrators accounts should be examined to meet the organization's needs.

Common security configuration mistakes are detailed in a guide from CISA and NSA, which notes the compromised defaults, weak access controls, poor monitoring, among other problems that can be exploited by adversaries.

Does the Cloud Provider Protect Everything?

One of the biggest misconceptions about cloud security is the belief that the provider handles everything.

The provider can assure the safety of the data center and physical infrastructure, along with core services; however, internal user accounts, file-sharing configurations, access permissions and passwords more often than not remain in the customers domain. That means the office might be in a safe building, but there are always people who could leave the front door unlocked.

As a result, cloud security is not only the responsibility of the technical team. Consistently check who has access to what resources, disable accounts that are no longer in use, and monitor who modifies important settings.

How to Avoid Misconfiguration?

Your first task is to find which files or storage areas are publicly accessible. Review accounts with administrative privileges, disable unused user accounts and check whether test systems are still live.

It is vital to keep track of important modifications. When it changes and you don't know who is responsible for the change, how are you able to trace that back to a particular person?

These risks can be greatly reduced by regular security audits, automated alerts and policies for restricted access

The Importance of Proper Configuration

Even the most sophisticated cloud systems can suffer a breach due to a single basic mistake.

An accidentally checked box, a leaky test environment, or excessive permissions can be enough to compromise an environment.

As such, in cloud security, the configuration of a system is equally as important if not more so than the resiliency of a system itself.

Simply locking the door is not enough. Additionally, it is important to know who has the key and what doors it unlocks as well as whether any unused keys have been formally revoked.

Disclaimer: This content is prepared for informational purposes only. Nothing contained herein constitutes professional cybersecurity consulting.

‍