All the sessions from Transform 2021 are available on-demand now. Watch now.
Whenever there is a report of a compromised cloud server or exposed data, it’s highly likely the incident is a result of mistakes made while provisioning or configuring that cloud system. If IT teams don’t consider the context that allowed those actions to occur in the first place, their remediation efforts will not be as effective.
Misconfigured or over-provisioned cloud access is “inevitable,” wrote Lori Robinson, the vice president of SailPoint, a cloud-based identity security provider. Even with the “most carefully crafted governance framework” in place, the sprawling nature of the cloud environment and the variety of changes constantly taking place means specific procedures are bypassed at times. Immediately revoking access once the problem has been uncovered is a “knee-jerk reaction,” according to Robinson. IT teams should first figure out what the impact would be on existing applications and processes in order to determine the appropriate course of action.
Even if the original decision was made erroneously and without following proper procedures, there was still a reason the action was approved, Robinson noted.
Misconfigured access is a common problem, as the cloud instance is set up without the proper security or access controls. A database or storage server intended to be used for internal applications may be accessed by anyone on the internet. Access logging or encryption may not be enabled. Authentication may be weak — or missing entirely. When this happens and the information is exposed, it puts the individuals at risk for identity theft and other personal cyberattacks, and organizations can face regulatory action.
Earlier this year, an unprotected AWS S3 bucket exposed over 400GB of data, representing approximately 500,000 documents related to MCA Wizard, an iOS and Android app developed by Advantage Capital Funding and Argus Capital Funding. The data in the database included credit reports, bank statements, contracts, legal documents, driver’s license copies, purchase orders and receipts, tax returns, Social Security information, and transaction reports. In a different incident, over 50,000 patient records at a Utah-based COVID-19 testing service were exposed due to a misconfigured AWS S3 bucket. The S3 buckets, which contained around 200,000 images of scans of driver’s licenses, passports, state ID cards, medical insurance cards, and other identification documents, had been indexed by search engines and could be accessed over the internet without a password.
Over-provisioning is a bit more complicated, as it means users have been assigned more privileges than necessary. If the user is assigned to a role with permissions beyond what they need to perform their tasks, that presents a security risk. This could occur because the roles are too broad or it wasn’t initially apparent which role would be most appropriate for the user. If the user is assigned an engineering role with 100 access controls but uses only 15, for example, that is a provisioning issue. The principle of least privilege works in reverse — giving users the fewest number of permissions and escalating access if they need more for specific tasks.
Risks of automated mitigation
Developers are increasingly automating manual tasks and speeding up configuration and execution within cloud deployments with reusable patterns and code templates. That means some of those misconfigurations or over-provisionings are happening as part of an automated workflow. Changing the settings on those systems without understanding how and why the access was granted in the first place could potentially break the pipeline, causing applications and deployments to fail. Or the processes will keep overwriting changes.
“By not understanding the origin of that access, chances are the automated processes will simply override any local changes made the next time the automated deployment happens again,” Robinson wrote. “So, the work you did to revoke that access is futile because that access will soon magically appear again upon the next cloud workload deployment.”
Without context for why the roles are provisioned the way they are, blindly removing access could have downstream effects, potentially shutting out teams and new projects.
“Automating the monitoring of cloud access is a good first step — that provides you the ‘what.’ But you also need to know the ‘how’ and ‘why’ to fully understand how such access is being granted in order to effectively govern,” Robinson declared.
VentureBeat’s mission is to be a digital town square for technical decision-makers to gain knowledge about transformative technology and transact.
Our site delivers essential information on data technologies and strategies to guide you as you lead your organizations. We invite you to become a member of our community, to access:
- up-to-date information on the subjects of interest to you
- our newsletters
- gated thought-leader content and discounted access to our prized events, such as Transform 2021: Learn More
- networking features, and more