The root cause of most incidents is an honest mistake as opposed to a malicious action, recent cloud misconfigurations research from Rapid7 found. The report summed this up by invoking 18th century poet Alexander Pope: "To err is human."
Rapid7 identified 121 publicly reported data disclosure incidents in 2020 that were caused by cloud misconfigurations. The most common culprits: poorly protected Amazon Simple Storage Service (S3) buckets and Elasticsearch databases.
"There are so many organizations with so many groups using the cloud that have no structure in place for who controls what," said Bob Rudis, the chief data scientist for Rapid7. "People build and deploy to the cloud. They set it and forget it, but all it takes is one person with administrative access to click the wrong thing, and it's all public."
Most disclosures are both unintentional and addressed quickly, Rapid7 found. All told, more than 60% were discovered by security researchers, not attackers. Roughly 85% were remediated within one month of discovery.
That doesn't mean the incidents were minor — 52 involved the disclosure of at least 1 million records, more than two dozen disclosed at least 10 million records, and the largest leaked 20 billion records.
Blame policies, not users
Cloud misconfigurations result from improperly setting up cloud architecture, creating unintended entry points to networks and data.
Rudis and other cloud security experts attribute cloud misconfigurations to one of three oversights:
- Not understanding what configuration settings mean
- Sticking with outdated default configurations
- Giving too many users too much access to configuration settings for databases, containers and data searches.
These oversights shouldn't be blamed on the actions of individual users, said Sean Curran, senior partner and national leader of cybersecurity consulting for West Monroe. Rather, they are the result of global policies that focus on ease of use instead of security.
"A lot of administrators move to the cloud quickly," he said. One former client in the financial industry brought the BlackBerry email connector into production in just three weeks due to demand from executive leadership. "It had zero redundancy or any of the security features you would expect, but someone saw that it was cool and functional, so they accelerated without configuring the environment the right way the first time."
Legacy configurations can also pose a problem. Several years ago, Amazon S3 and Elasticsearch had poor default settings for cloud configurations, Rudis said. "You were pretty much just leaving it out there for anyone to discover."
These settings have since been tightened, as have the configuration settings for Microsoft Azure and Google Cloud. Unfortunately, a lot of organizations aren't taking advantage of them. They simply take their old installs, initially developed according to the legacy configuration settings, and copy and paste them from an internal server to the public cloud, Rudis said.
"Everyone's in a hurry, so they just do that," — and then data disclosures happen, he said. "It's not that hard to find these things and notify an organization that they might have a leak, but organizations don't seem to use the resources at their disposal to do the checking. They don't realize it's a bad configuration."
Security tools help, but best practices are better
One step in reducing the likelihood of a disclosure caused by cloud misconfiguration is a policy audit. This should result in adopting the newer, stronger configuration defaults from cloud service providers, as well as setting overarching policies for certain storage buckets of data types, Rudis said.
A policy audit also helps organizations uncover opportunities to improve cloud security best practices. The learning curve here should be gentle, as these steps are no different for IT professionals than the traditional on-premises environment, said Brian Adler, senior director of cloud market strategy at Flexera.
"Cloud deployments that are as secure as their on-premises counterparts are possible via the best practices implementation of the shared responsibility model," he said, referring to the framework by which a cloud service provider and an organization's IT team are accountable for different aspects of cloud security.
To that end, Adler recommended that organizations take advantage of the security toolkits that cloud service providers offer, including but not limited to virtual private clouds, public and private subnets, and network access control lists.
These can restrict the "blast radius" of a misconfiguration to a single subnet, he said, limiting an attacker's impact.
Third-party products for policy enforcement, asset inspection, and identity management can help, but Adler said these tools are only as good as the security foundation that an organization has already built. That foundation should include automating as many of the "nuanced details" of cloud configuration as possible to reduce the likelihood of a data disclosure that results from human error.
Curran agreed. "If you follow security best practices, then the end user doesn't have the privileges to make changes. That's what makes you insecure."
