Sealing Off Your Cloud’s Blast Radius

Understand the challenges of securing your cloud and key best practices for minimizing your cloud’s blast radius

Migrating to the cloud? Complex cloud security requires a shift in mindset from traditional on-premises security. Implementing relevant principles and practices, like for permissions management, can mitigate vulnerabilities and significantly reduce the blast radius of an attack. In this blog post, we dive into the differences between on-premises and cloud security, outline the main challenges in securing the cloud and provide solutions for security teams to implement.

This blog post is based on a discussion between Rafal Los, of the “Down the Security Rabbithole” podcast and Arick Goomanovsky, Tenable’s Chief Product Officer and VP of Cloud Security, on the topic of the biggest risk in cloud infrastructure.

What’s different about cybersecurity in the cloud

In some organizations, security professionals and organizations address cloud infrastructure security in the same manner they used for on-premises security. While the same general concept of cybersecurity remains, i.e keeping the bad guys out, the security principles and way to implement them are very different.

The two most distinguishable differences between the cloud and on-premises infrastructure are understanding what constitutes the perimeter and what the most important control plane is. On-premises, the perimeter was based on connectivity: the internal organizational network was the perimeter, demarcated by security mechanisms such as firewalls, intrusion detection systems and application layer file rules.

In the cloud, however, identity is the perimeter. With organizational data and systems dispersed globally and employee reliance on SaaS applications and the internet, it is no longer possible to draw definite borders between what part of the architecture is owned by the enterprise and what part is owned by infrastructure vendors, application developers, software companies and other third parties. Therefore, system and resource access is now determined by identities. These digital identities are the new way for enterprises to determine their borders.

The dynamic nature of identities, compared to the rigidness of the hardware perimeter, make it imperative to update the cloud infrastructure control plane. Permissions management, i.e determining who has the rights and ability to access organizational resources in the cloud, is the new control plane for digital identities. In addition, these permissions will also dictate which and if organizational resources are publicly exposed and to what extent.

The challenges of permissions management in public cloud infrastructure

Transitioning your legacy security methods to identities and permissions is not that easy. The number of digital cloud identities for each organization is usually in the thousands, resulting in tens of thousands of permissions that require close and precise management. It’s not just human users that have identities. Service principals have identities and permissions too, which they require to perform the activities that keep the business running — like pulling data from a database. For example, an AWS S3, which is only one of the hundreds of services an organization might be building on AWS, may have anywhere between 10 to 50 to 100 (or more) permissions.

This creates a complex environment that requires constant monitoring and management to ensure a deep and continuous understanding of which permissions have been assigned to which identity and how services have been configured. Having this understanding is essential to ensuring that all identities have access to the resources they need, with no excessive permissions provisioned. Excessive and unmonitored permissions or misconfigurations of the infrastructure put the enterprise at risk, since they increase the attack surface and give attackers access points into valuable resources and data.

In multi-cloud environments that employ a number of clouds, such as AWS and Azure, or AWS and GCP, or more, the challenge is intensified, since identities need to be managed across different cloud providers that are not seamlessly integrated by design. This requires IT and security teams to have a good understanding of how to provision and monitor permissions in each cloud environment, and without letting the differences between provider security approaches, mechanisms and practices affect the business or security.

But don’t just take our word for it:

• Verizon’s 2022 Data Breach Investigations Report (DBIR)]: Credentials are the number one attack vector
• IBM’s Cost of a Data Breach Report 2022: Stolen or compromised credentials have been the number one attack vector in the past two years
• IDSA report: 84% of respondents had an identity-related attack in the past year.
• Gartner: “Through 2025, 90% of the organizations that fail to control public cloud use will inappropriately share sensitive data.”

Why is permissions management in the cloud so difficult? The difficulty nets out to three main problems.

Problem #1: Too many cooks in the kitchen

One of the most impactful organizational shifts of cloud adoption concerns who is responsible for the infrastructure. In the on-premises world, IT was at the helm. In the cloud, responsibilities are more distributed. Responsibility for cloud infrastructure involves IT, as well as security teams and developers.

Not all these stakeholders understand cloud security to the same degree. Moreover, for some, cloud security is not necessarily a priority. Developers are usually not measured on the security of their code or configurations; they are expected to push code to production as fast as possible. The underlying assumption for many developers -- accidentally or not -- is that cloud infrastructure risks, like misconfigured permissions, come second to development velocity.

This brings us to the second challenge.

Problem #2: Permissions management Misconfigurations in development

In many data breach incidents, including heavyweight cyberattacks that make headlines, the types of attacks are not always very sophisticated or based on a unique zero day vulnerability. Instead, attackers often take advantage of permissions management misconfigurations that are the result of human errors and oversights. These may include:

• Giving excessive permissions to resources or leaving them publicly exposed, like accidentally configuring an AWS principal with an asterisk and providing any identity with access to it.
• Leaving access keys in open source code, publicly available on GitHub. These could even be developer credentials that provide access to the infrastructure environment.
• Using public cloud provider default settings or static credentials.

In the infamous and tectonic Capital One breach, the attack was based on the attacker’s ability to scan and identify a publicly exposed infrastructure vulnerability. Then, due to a misconfigured web application firewall (WAF) accidentally provisioned with excessive and privileged IAM permissions, she was able to access a sensitive AWS S3 bucket. She exploited this to access the personal information contained in more than 100 million credit applications. All in all, the breach was a case of overlooked misconfigurations and excessive permissions.

Another common and not entirely complicated misconfiguration use case is crypto mining. When identifying a misconfigured machine, the threat actor installs a crypto miner on it and leeches off the enterprise’s computing resources while benefiting financially.

But why are configurations fortified against such breach weaknesses so complicated to create and maintain?

Problem #3: Permissions spaghetti

The key to solving permissions management and misconfigurations is by implementing principles of least privilege and zero trust. This permissions frugality minimizes the blast radius because it ensures that even in the case of a breach, an attacker won’t be able to progress laterally and compromise sensitive systems and data. In the Capital One case, for example, the principle of least privilege could have prevented the attacker from accessing credit application data, since the misconfigured WAF would not have had that type of access.

But cloud environment complexity makes it challenging to implement this noble principle. Cloud infrastructure environments were built for engineers and machines, and require deep technical knowledge to manage. It’s not enough to observe traffic. Permissions and configurations management requires scanning all environment resources and meticulously identifying even the most miniscule of errors in JSON permissions documents to ensure no policies have been accidentally misconfigured. With tens of thousands of permissions to look into at any given time, enterprises need either an army of IAM/IT professionals or a different type of solution.

Cloud environment complexity becomes even more challenging when applications are run across multiple public cloud providers, in what is known as a multi-cloud infrastructure. For example, an enterprise might run its backend services on Azure and its front-end on AWS. In this case, users are accessing two public cloud vendors to use the same application.

Additional common examples are when organizations use Office 365; they use servers on Azure but some of the development takes place on AWS. Another example is when a company merges with or acquires another company that has been using a different public cloud vendor for their infrastructure.

How does the permission structure work in this case? Building a manual permissions table that covers traffic routed between the two vendors and also incorporates zero trust is extremely difficult. The identity provider of one cloud, such as Microsoft’s Azure ID, which is probably also incorporated with SSO, cannot be used for access to AWS. In many organizations, this multiplicity of identity and permissions mechanisms turns into permissions spaghetti. The native tools of individual cloud providers do not cover other cloud environments; a multi-cloud solution is needed.

Photo Credit: Rick Mason on Unsplash

Third-party solutions are here to help

Putting the burden of permissions management on developers, IT or security teams without proper processes, training and tools is unfair and can be stressful. Manually managing permissions in a spreadsheet is not the best approach to overcome this challenge.

Instead, a third-party solution can ease the friction and challenge of permissions management in complex cloud environments. Such a solution can automatically implement the principle of least privilege, mitigate misconfiguration risks and seamlessly integrate into daily development and security workflows. A frictionless solution will also bridge the notorious gap between development and security teams.

Such a solution should be able to provide capabilities according to these criteria:

• Automation - A solution that provides a machine-based process that constantly runs and monitors permissions management and misconfigurations audits, and highlights and auto-remediates risks. Automation reduces manual errors, enables identification and remediation at large-scale (an effort impossible to do manually) and frees up teams for tasks of higher productivity.
• Visibility - Permissions spaghetti requires a solution that can cut through the complexity and easily visualize which identities have permissions to access which resources. By providing a graphical and human understandable picture of permissions, with actionable insights, permissions management complexity becomes workable.
• Least privilege including with JIT - Reducing risk requires enforcing least privilege, made possible with capabilities like automated right-sized policies sent through workflows and just-in-time (JIT) access, which operationalizes least privilege using a defined approval process and keeps developers productive without putting the environment at risk.
• Integrating with CI/CD - Enabling developers to push least privilege configuration changes automatically into their CI/CD pipelines. This helps deliver security faster and maintain agility, while removing most of the development heavy lifting from engineers.
• Third-party tracking - Monitoring which third parties have potentially risky — over-privileged or elevated — access to sensitive resources. If required, alerts can be issued for such permissions risk and the risk removed.
• Real-time monitoring - Monitoring for misconfigurations in real-time, such as when rolling out features to production.
• Audits and ongoing tracking - Continuous real-time monitoring and audits to detect misconfigurations in infrastructure and policy management. These can be used for internal security audits as well as complying with regulations. Logs from VPC flows are a start, but they don’t always have the required information for understanding what is being accessed and alerting about any anomalies.

What’s next for security teams

Cloud infrastructure might be complicated, but it’s workable. Once security and engineering teams understand the inherent differences between on-premises and the cloud, they can begin to build and implement a security and development plan that incorporates those differences into their day-to-day.

But they shouldn’t have to do so by themselves. Permissions management is one of the riskiest attack vectors for cloud environments, yet it is not a challenge easily overcome with a better spreadsheet, task management tool or more personnel. A quality solution can provide the necessary capabilities for managing and monitoring permissions in the cloud. By incorporating automation, visibility, auto-remediation and monitoring capabilities, some of the main difficulties of securing the cloud are minimized as is the blast radius of your cloud infrastructure.