Wiz Research: 82% of Companies Give Third Parties Broad Cloud Read Access
Summary
An analysis of more than 1,300 AWS accounts found widespread excessive third-party IAM access: 82% allowed broad read access, 76% had roles enabling account takeover, and over 90% of security teams were unaware of high permissions.
Key points
- Wiz analyzed external IAM roles across more than 1,300 AWS accounts and 40+ popular third-party vendors; the article says similar issues are seen in Azure and GCP.
- 82% of organizations had third-party roles with wide read access, and over 90% of cloud security teams said they were unaware of the high permissions.
- 76% of organizations had at least one third-party application with permissions the analysis said could allow complete account takeover.
- 15% of vendors received extensive write permissions that could modify active cloud resources.
- A quarter of the vendors requested AWS ReadOnlyAccess, which the article says can expose data in services such as databases, DynamoDB, and S3.
- The research describes escalation risks involving iam:PutRolePolicy and lambda:AddPermission, and recommends limiting permissions to necessary resources and conditions, monitoring vendor roles, and removing access when no longer needed.
Article Details
- Publisher
- Wiz Research
- Scope
- Direct exposure through third-party IAM roles, primarily in AWS; similar risks were noted in Azure and GCP.
- Sample Size
- More than 1,300 AWS accounts and 40+ third-party vendors
- Key Statistics
- 82% of organizations gave third parties wide read access in their environments.
- 76% of organizations had at least one third-party application that allowed complete account takeover.
- Over 90% of cloud security teams said they were unaware that a third party had been given highly privileged permissions.
- 15% of vendors received extensive write permissions that could modify active cloud resources.
- 25% of vendors in the research requested the AWS ReadOnlyAccess policy.
- Recommendations
- Review third-party permission requests and reduce permissions to the minimum required.
- Restrict high-risk permissions to specific resources and apply conditions, such as limiting which roles or Lambda functions they can affect.
- Monitor third-party roles with high privileges and remove unnecessary permissions.
- Maintain a list of active vendors and applications, and remove their roles when the relationship ends.
- Coordinate permission changes with vendors when needed to avoid disrupting critical applications.
Vendors
NewRelicpermissions this broad. Lets take a closer look at one of the leading vendors asking for ReadOnlyAccess: NewRelic. While the vendor has extensive documentation on how customers can restrict access, we found that mostSpotYou’ll see that most escalations are subtle and require an experienced AWS cloud security engineer to spot them. Moreover, we found that based on vendor documentation, these permissions are not required in most
Products
AWSand the customer team isn’t even aware that they gave them to the vendor. The most common example is the AWS ReadOnlyAccess policy, which is extremely popular amongst 3rd party vendors (a default for 25% of vendorsAWS LambdaEscalation path #2 – lambda:AddPermissionAzurethe data is AWS-focused, the risks we discuss are cross-cloud, because we are seeing similar issues in Azure and GCP. This research focuses on direct exposure via IAM roles.GCPis AWS-focused, the risks we discuss are cross-cloud, because we are seeing similar issues in Azure and GCP. This research focuses on direct exposure via IAM roles.