6 Cloud Security Tips For 3rd-Party Risk

It's critical to understand the security risk that third parties pose to your cloud infrastructure and how managing third-party access using secure practices can help.

If you’re like most modern organizations, you rely on third parties to help you run and grow your business. Yet the vendors, partners and suppliers that make up your supply chain are also a significant component of your cloud environment attack surface.

While you can’t (and shouldn’t) cut third parties off completely, you can (and should) enforce the principle of least privilege when providing them with permissions into your single, hybrid and multi-cloud environment. Read on to learn how to implement this essential modern security practice and tips for getting started.

Why are third parties so risky for your cloud environment?

Third parties, including suppliers, contractors, vendors, eCommerce stores, partners and even your cloud provider are a fundamental part of your organization’s business ecosystem. They help with any and all aspects of business growth, from engineering and IT to marketing, business development, legal and strategy. Many of these third parties have other third parties they work with to help run their own businesses, and so on. This natural business reality creates a supply chain of companies and networks interlinked in various ways.

But all this help has a dark side: third parties and supply chains create considerable vulnerabilities in your cloud environment. According to IBM’s 2022 Cost of a Data Breach Report, 19% of breaches were caused by a supply chain compromise. The average total cost of a third-party breach was $4.46M, which is 2.5% higher than the average cost of a breach. In addition, identifying and containing third-party breaches took an average of 26 days longer compared to the global average for other kinds of breaches.

The vulnerability of third parties arises from the different security hygiene practices and controls each business in your ecosystem employs. In many cases, their standards are less stringent than your own, creating inconsistency and an increase in their relative security vulnerability.

In May 2021, U.S. President Joe Biden dedicated an entire section in his monumental CyberSecurity Executive Order to the hardening of the supply chain and mitigation of risks of vendor attacks. The order states that “the development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.” It notes that due to its being easier for an attacker to breach, third-party software is more susceptible to exploitation.

Third-party vulnerabilities are not just software-related. Security practices that are different, mismatched and/or below your organization’s own security standards also create vulnerabilities. For example, as in the case of the SolarWinds attack, some third parties may not practice password hygiene. In other cases, they may be reusing credentials or accidentally misconfiguring their environments.

Once they gain access to your supplier, attackers may find it easier to access your environments as well. Unlike malicious attackers, for which organizations are on the alert, organizations tend to treat third-parties as trusted entities. As such, third parties are granted access and control over sensitive resources. Sometimes, this access is required for them to perform their work. Too often, though, permissions are intentionally or unintentionally over-privileged – due to manual errors, oversight or not knowing better. As a result, attackers that access your vendors can exploit this trust and breach your environments as well. Overprivileged permissions put your critical systems and data at risk, and can disrupt your compliance with regulations.

Third-party security in the cloud: Why the risk is different from on-premises

In the cloud, excessive trust of third parties and supply chain actors is riskier than on-premises environments — not just because one’s guard is down, but due to the nature of cloud architecture and how it differs from on-premises.

On-prem local servers and components enabled delineating network borders and implementing security controls to protect those borders, like firewalls. But in the cloud, infrastructure is distributed and resides on public infrastructure, making surrounding it with security controls impossible. This means that previously used security tactics and solutions like third-party PAMs are no longer helpful.

In addition, the distributed nature of the cloud, alongside the workforce’s reliance on cloud-based resources for their work (e.g, on SaaS apps), has changed connectivity needs. Businesses going through cloudification now rely on identities and credentials as the main means for providing access to company resources, making identity the new security perimeter.

It’s not only human users that require identities for access; the cloud has transformed many architectures from monoliths to microservices to support more development agility. These cloud services now also need digital identities as their main means for resource access. In some cases even your cloud provider can be a third party with access, often authorized, to your environment. Still, maintaining a list of CSP-managed accounts can be a difficult task.

Identities: A complicated security affair

In the cloud, IT, DevOps, security and DevSecOps are now managing thousands of new digital organizational identities, each with a complex subset of permissions that determines which resources they can access and the actions they can take on those resources. In the recent 2022 Trends in Security Digital Identities survey, by the independent group Identity Defined Security Alliance (IDSA), 52% of identity and security professionals identified cloud adoption as the driver of the growth of organizational identities.

Managing and monitoring these identities and their permissions is extremely complicated. The combination of the high volumes of identities and the intricacies of their permissions makes it almost impossible to avoid oversights and manual errors.

This extreme difficulty in avoiding permissions error has dangerous security implications. Verizon’s 2022 Data Breach Investigations Report (DBIR) finds that credentials are the number one organizational security weakness. When it comes to third parties, the same research finds that the use of stolen credentials and ransomware are the top two “action varieties” leading to incidents. Per Tenable Cloud Security ransomware research, ransomware potential lies in misconfigured identities, publicly exposed machines, risky third-party identities and risky access keys.

In other words, third-party credentials are a focus point of violation for attacking companies and breaching their data. Protecting third-party credentials needs to be part of everyone’s security strategy.

Third parties: A global necessity and pain

Businesses operating in a legacy security mindset tend to block any risk or threat, but modern security strategies require security teams to act as business enablers. This means security needs to be maintained without slowing down business productivity and performance. Overcoming the third-party business vs. security dilemma is challenging, since while the supply chain is an inherent risk, it is also essential to a business’s success. Shutting down third-party operations is equivalent to shutting down business operations.

But the risk speaks for itself: third-party access in the cloud requires a dedicated security approach to permissions management. Fortunately, the principle of least privilege is the modern security practice that can answer identity management complexity — including that of third parties — in the cloud. By minimizing user and service permissions to only those deemed necessary for business operations, organizations can reduce their blast radius and attack surface in case of an attack.

When it comes to third parties, the principle of least privilege — including its implementation via tools like just in time (JIT) privileged access – enables providing third parties only with the necessary access for the business while minimizing the risk these entities pose.

Implementing the principle of least privilege for third parties in the cloud

Let’s look into the various options for managing the risk of third-party permissions with least privilege.

Solution #1: Manual maintenance

To secure third-party access to resources, IT and security need to find a way to keep track of all identities and their permissions. Some businesses rely on manual tracking in spreadsheets or other similar means. This quickly turns into long lists of identity names, the resources they have access to and their permissions.

However, manual maintenance in spreadsheets or by other means cannot capture the complexity of permissions management requirements. Many identities have access to a large number of resources, each with different authorization requirements. These all need to be meticulously tracked – spreadsheets are not equipped for presenting this information in a consumable fashion.

In addition, permissions can be inherited. This means that if service A has permissions to control service B, and service B has permissions for service C, service A will have permissions for service C. This creates a complex chain of permissions that is hard to create and visualize manually.

Excessive permissions derive from a complex chain of permissions that is hard to determine, visually present and keep up with manually

Finally, permissions need to be continuously monitored. Creating a one-time picture of permissions does not reflect the mercurial nature of the cloud or legitimate needs that come up requiring elevated or expanded permissions be granted for a certain amount of time.

Scanning and reviewing all these permissions takes time and concentration, which many IT and security teams don’t have. In addition, understanding the complexity, depth and how permissions are intertwined requires cloud security expertise, which not all security and IT teams have or have had time to develop. Even if they did, is this the best use of their time?

Here’s an example of one JSON permissions doc. Imagine having to comb through thousands of these and identifying any errors or issues:

Typical JSON permissions document - wherein lie the risky permissions?

Solution #2: Automation and least privilege to reduce third-party risk

Constantly updating manual spreadsheets while also being able to pinpoint any excessive or toxic permissions requires painstaking tracking, which resembles the type of analysis a machine — not a human — would perform. The required level of detail, the scope of data and the speed of decision-making required when managing and monitoring the principle of least privilege screams “automation.” Doing so in a multi-cloud, let alone single cloud, environment is daunting.

Here are six tips for ensuring your automated mechanism can protect you from third-party risk with least privilege:

Tip #1: Monitor for excessive third-party permissions

As we’ve established, permissions in the cloud are convoluted by nature. An automated, multi-cloud monitoring mechanism will check third-party credentials for excessive permissions or toxic combinations and identify if these permissions violate the principle of least privilege by providing them with the unnecessary ability to access sensitive data and modify infrastructure. This information will be visualized by its risk severity, and any attacker reconnaissance capabilities will be highlighted. The evaluation of severity will take into account any risk offsetting covered by other policy definitions, including network related, along the permissions chain.

Tip #2: Monitor with care and context

Modern security strategies are business enablers and growth enthusiasts. Therefore, security controls need to be applied in a contextual manner. Rather than blocking any potentially vulnerable activity, actions need to be implemented intelligently. With permissions, it is essential to provide context of permissions scope. Not all third-party capabilities are dangerous for the business. Excessive permissions, i.e., those that exceed the principle of least privilege, are the ones that should be mitigated. Automated security controls provide mechanisms for marking accounts and services as trusted, reducing false alerts.

Tip #3: Auto-remediate third-party vulnerabilities

Engineering, IT and security teams are busy and have alert fatigue. A helpful automated solution does not just highlight the problem, but also helps solve it. Instead of adding more tasks to the team’s full plate, choose a solution that can provide a recommended substitute policy and auto-remediate into your organization’s workflows, and even shift left with optimized policies through infrastructure as code (IaC), while leaving more advanced issues to human judgment.

Tip #4: Set permissions guardrails

Guardrails limit the actions an identity can perform. This helps minimize the blast radius by capping the potential of what a user or principal can do. Determining automated guardrails are especially important with third-parties, since it is often easier for IT teams to provide them with excessive access or accepting the cloud vendor’s default configurations rather than having to go into the weeds and figuring out how to limit their permissions to the resources they actually need.

Tip #5: Ensure ease of use

Automation should support you, not make your daily flow more difficult. A helpful automated solution will integrate with the security and engineering teams’ workflows. This can be done through easy to understand dashboards, clear instructions, integrations into the CI/CD cycle and integrations with tools like Slack or PagerDuty.

Tip #6: Deliver JIT access

Just-in-time access is a security principle that provides access to users for a limited period of time and then revokes it. JIT is useful when users need permissive entitlements to complete a certain task, such as when developers need to fix a bug in production.

A secure automated solution will support JIT access for third parties as well. That way, if your vendor needs to access a sensitive environment for an important work-related issue, you can provide them with such access without leaving attackers with a permanent window of opportunity for reconnaissance.

Conclusion

From a business perspective, third parties are as much a part of your business as any internal department. But from a security perspective, these entities need to be approached intentionally and with strategic caution. Third parties carry huge risks since their security practices are beyond your control.

The answer to managing these vulnerabilities is through an automated security solution that enforces least privilege and JIT access. Automated permissions management and monitoring reduces access risk by assigning third parties, including developers, with only the access they need. This is the best way to balance and ensure business continuity and security in your cloud.