3 Steps for Avoiding Unintentional Exposure

28/11/2021 • Gabriel Avner

Being the subject of any data leak can leave you feeling a little bit naked, having your private information exposed for all to see.

But there are matters of degree.

According to reports, the adult site StripCam had its ElasticSearch database cluster exposed to the internet without a password for at least three days in early November. This led to the leakage of a trove of harmful information, including:

  • Data for 65 million users, and lots of it including identifiable details
  • Slightly less revealing information about 421k models
  • A ton of transaction and chat information that nobody wants to become public record

You’d think that the StripCam site owners would put a little more effort into maintaining their customers’ privacy, or more importantly that of the performers who are likely to be the more impacted party.

But I wouldn’t count on it. And not just because of my high expectations from StripCam. These types of mistakes are so exceedingly common and can impact anyone.

Unintentional, Unforced, and Unfortunate Error

Looking at the Verizon Data Breach Incident Report for 2021, their researchers found that Miscellaneous Errors was the fourth leading cause of data breaches.

In some cases these can be a simple misconfiguration of the security policy, making an S3 publically accessible when it most certainly should not be. Those examples are egregious, but have happened far more times than they should have. AWS has since made their buckets private by default which has helped to cut back on this from happening.

What we do see regularly are internal and external exposures that leave the org open to unnecessary risk.

Let’s look at these two types of exposures and their similarities and differences.

Internal Exposures

Another way to think about the problem of internal exposure is that an identity is overprivileged and therefore granted access to more data/resources/capabilities than they should really have.

There are a number of ways that a user can be overprivileged.

Sometimes an org has permission sprawl where they end up doling out too many privileges. It is easier to give privileges out widely than check that folks actually need it. However, each additional privilege widens the threat surface. As orgs rack up more and more identities with the explosion of cloud app adoption, managing entitlements correctly becomes a much bigger challenge.

Internal exposures matter for a range of reasons. The two top ones being that the user may abuse their privileges to cause harm, or their overly privileged account may be compromised and its wide reaching access gives the attacker far more access to play with.

So how does this happen?

Beyond the straightforward direct granting of too many privileges, an identity can gain excessive privilege through poorly administered group membership.

Let’s say that a senior developer is added to all of the admin groups by right of being an admin in the R&D context. It is not hard to see how that person — we’ll call her Mary — is added to other organization admin groups. She might find herself gaining admin access/rights that should belong to Sales, giving her access to customer financial data and the ability to make changes in Salesforce.

Adding Mary to a group with admin privileges because she’s an admin makes sense, but it inadvertently gives her access that she does not need and can cause additional harm. An attacker that compromises Mary’s identity can move laterally to other areas of the organization with ease.

In this case, all we see here is risk with very little reward.

External Exposures

The cloud makes it easier than ever to share resources with partners outside our organization, enabling better collaboration. The challenge we face is that we grant access freely and then forget to revoke it when it is no longer needed.

Think for a moment about how many files you have shared externally and never shut off the access at the conclusion of the project. Maybe it was access to a private repo? It’s a bad habit that we’re all guilty of. In part because it seems like more of a hassle to have to resend access later, so better off leaving it open, right?

We know that leaving access to these resources open is a risk, but we often lack the visibility to see who else has access to them. This is because external identities are not a part of our federated systems, and we cannot control them or understand what they have access to from our IDP/SSO platform.

The only viable way to gain visibility is through understanding which permissions are associated with the shared asset, which requires having visibility over both the identity and asset sides of the permission equation.

Given these risks of exposure, what are the steps that we need to take to reduce our chances of a misstep?

3 Quick Tips for Reducing Exposure Risks

Humans will always make mistakes because we are, well, human.

Thankfully there are measures that we can take to limit the damage that they can cause and in some cases, even prevent a risky exposure situation from turning into a disastrous one.

Below are a few useful tips.

Manage Authorizations Through Groups

Best practices call for providing privileges through group membership and not through direct entitlements. This method helps to maintain control over what types of access your people are granted, and prevents them from retaining specific entitlements as individuals.

Frankly it also just makes it easier to manage because you are only adding and removing people from groups instead of trying to fine tune an individual’s privileges. Hopefully leaving less room for error.

Use Tools to Gain Visibility into Group Privileges

Preventing a user from becoming overprivileged requires granular understanding over all of the entitlements in a group and what that user’s right-sized privilege profile should look like.

Managing this job at scale requires automation and tools that leverage data from both the identity and asset stacks to detect when someone gains unnecessary and risky privileges.

Continuously Monitor for Unused External Share Permissions

Understanding permission usage is key to identifying externally shared assets that may become risky for your organization. If an asset hasn’t been accessed by the external partner in some time, say 30 or 60 days, then it can probably be revoked.

Continuous monitoring of permission usage is a critical component of effectively enforcing these policies. Using Authomize’s security policies and guardrails, you can ensure that these permissions do not remain open indefinitely and create gaps in your security.

Hope for the Best, Mitigate for the Worst

Mistakes will happen, but it is up to us to put the right tools and practices in place that will reduce our chances of damaging our organization.

Automation that leverages comprehensive data collection and analysis can help remove many of the unforced errors and unseen risks that are often at the center of asset exposures.

For more insights on mitigating IAM risks, read our most recent White Paper, Identity-First Security — Identity is the New Perimeter for the Zero Trust.

Next read

Solution Brief

Learn how Authomize's solution is changing the way companies are managing authorizations