The Cloud Security Risks of Overprivileged Vendors – Source: securityboulevard.com

Security and engineering teams are constantly adopting new technologies in their cloud environments, either to increase the velocity of development and deployment cycles or to better secure their network as their cloud footprints grow. This often means deploying open source software solutions or buying commercial software or solutions from SaaS vendors that assume delegated authority in the customer environment. While the industry seems to recognize the risk associated with the software supply chain, with progress being made on requiring vendors to document a software bill of materials (SBOM), the same level of scrutiny appears to be missing when it comes to the cloud supply chain. 

An SBOM is a formal record containing the details and supply chain relationships of various components used in building software. There is no analog to this when it comes to describing and understanding the risk associated with the variety of vendors operating with delegated authority within cloud environments.  Organizations will often just check to see that the SaaS provider has a SOC 2 Type II certification, run them through a security questionnaire and then deploy. We’ve observed that an average enterprise will have 10 or more vendors operating via delegation in their cloud environments. 

Onboarding new vendors in the cloud, however, presents a new set of security challenges for a lot of organizations. Ultimately, these technology providers need access to sensitive operations, data, logs, other applications and services to operate effectively and provide value to the user. Granting these vendors access and permissions in your environment introduces a whole new set of security challenges-ones that are mostly overlooked in the name of expediting the onboarding process. 

Vendor Risk is Growing

While vendor risk has certainly been a growing area of risk for most security teams, it is sometimes security vendors themselves that are far too overprivileged and thus, can present some of the biggest challenges to security teams. The question becomes: What do you do when the vendors you entrust to secure your cloud are the ones that pose the biggest risk to an organization’s cloud supply chain in your environment? 

In 2022, we found that on average, nearly 95% of all privileges granted to vendors across all identities and roles were unused. Similarly, about 90% of privileges went unused in cloud security posture management (CSPM) vendors-the vendors entrusted to help reduce the attack surface of cloud environments. It isn’t uncommon for vendors like these to ask for a lot of permission in order to assess as many of areas of the cloud environment as possible, but overprivileged users, especially vendors, continue to pose the largest risk in cloud environments. Now that advanced threat actors are more actively targeting cloud vendors, more specifically cloud security vendors in orchestrated supply chain attacks, the risk of overprivileged vendors is now increasing exponentially. 

“APT29 (aka Nobelium) executed one of the most advanced, well-orchestrated attacks in the last several years with the SUNBURST software supply chain compromise. This group and others are now targeting the cloud supply chain. Based on just how significant the permissions granted these vendors in customer environments are, if APT29, or another adversary, is able to gain access to a major cloud security vendor, they would have keys to the kingdom,” explained SVP of P0 Labs, Ian Ahl.

“Threat groups gaining access to any one of a handful of cloud security vendors out there would be devastating. If vendors who are involved in continuous integration/continuous deployment (CI/CD) tooling were compromised, they could steal source code or inject nefarious code into our deployments. They could also modify controls allowing them to bypass pull request (PR) checks when they shouldn’t – these actions would have a significant impact on any business. Assuming the delegated authority of a cloud role would have the same impact as a bad actors gaining access to service accounts” said Rob Preta, head of cybersecurity at ACV Auctions.

Vendor risk looks much different in the cloud than in on-premises environments. Vendor risk used to be more about software supply chain risk or poking a hole directly in or out of your environment in order for either systems or people to connect into the environment. Today, there is no traditional perimeter, as that same access is granted through delegation and OAUTH.

“We’ve seen some cloud security vendors behaving nefariously inside the environments of our customers. In one instance, we observed a cloud vendor escalating their own privileges in an environment. Asking for thousands of permissions that go unused and being overprivileged is one thing. Utilizing those permissions to then escalate your own privileges in a customer’s environment is concerning to us, even if it was for the purposes of rolling out a new feature without wanting to bother the customer,” Permiso co-founder and co-CEO Jason Martin explained.

What can you do the mitigate the risk vendors present in your environment? First, get a clear inventory of all the permissions they will require before onboarding with any vendor. They should be able to easily explain why they require the privileges they’re requesting and more importantly, what specifically they will be doing with those permissions. Often the sensitivity of the permissions they require can have toxic combinations leading to privilege escalation vulnerabilities. Being able to identify these vulnerabilities and building detection rules to notify teams if a combination of permissions that lead to a privilege escalation is observed is important. Each vendor presents a different level of risk to your organization, so if you’re managing 50 cloud security SaaS vendors in your environment, you have 50 different risk profiles to catalog. 

If you’re able to baseline their activity in your environment through logs, you can just as easily begin to develop rules and alerts to inform you when their behavior deviates from that baseline. Continuously monitor the ratio of privileges that are being used to those that have been granted and eliminate those permissions that are unused in order to maintain least privilege with your vendors.