As organizations increasingly move their data and workloads to the cloud, securing cloud identities has become paramount. Identities are the keys to accessing cloud resources, and, if compromised, they enable attackers to gain access to sensitive data and systems.
Most attacks we see today are client-side attacks, in which attackers compromise someone’s account and use their privileges to move laterally and access sensitive data and resources. To prevent this, you need visibility into your cloud’s identity infrastructure. Unless you know the identity of all the people and objects that are accessing systems, their permissions, and their relationships, you won’t have the context necessary to effectively assess your risk and take preventative measures.
A number of high-profile attacks illustrate this problem. A compromised cloud identity gave attackers access to SolarWinds’ Orion software, where they deployed malicious code to thousands of their customers, including government agencies and Fortune 500 companies. Another example is the Microsoft Exchange attack, in which attackers exploited a vulnerability in Exchange to gain access to email accounts. From there, they stole sensitive data and sent phishing emails in an attempt to compromise other accounts.
For securing the cloud, I advise implementing an approach known as applied risk, which allows security practitioners to make decisions about preventative actions based on contextual data about the relationship between identities and what the downstream impacts of threats are in their specific environments. Here are some practical tips for adopting applied risk.
Treat Cloud Protection as a Security Project, Not a Compliance Exercise
For starters, shift your mindset. Gone are the simple days of client-server computing. The cloud environment is a complicated system of data, users, systems, and interactions between all of them.
Checking a series of boxes won’t bring greater security if you don’t understand how everything works together. Most teams take an unguided approach to preventive security, putting blind faith in the prioritization and remediation strategy put in place years ago. Yet security requires a bespoke approach tailored to every security team based on the organization’s broader risk exposure. Not every “critical” alert from a security vendor is necessarily the biggest risk to that specific environment.
To accurately prioritize remediation and reduce risk, you must consider the entire attack surface. Understanding the relationships between exposures, assets, and users help you to determine which issues pose the greatest risk. When you take into account additional context, the “critical” finding may not be the biggest issue.
Get Visibility Into Your Cloud Identity Infrastructure
Next, visibility is key. To credibly identify the applied risk, you should do a comprehensive audit of all the identities and access control points in your cloud identity infrastructure. You need to know what resources you have in your environment, whether they’re in the cloud or on-premises, how they’re provisioned and configured, and other variables.
When securing the cloud, you can’t only look at how cloud-specific resources are configured — you have to audit the identity aspect: virtual machines (VMs), serverless functions, Kubernetes clusters, and containers, for instance. One admin may have an account tied to AWS, an Active Directory account with a different role to log into their local systems, an account on GitHub, a Salesforce account, etc. You also have to consider things like the hygiene of the machines that the developers, DevOps, and IT teams are using. A successful phishing attack on a DevOps engineer can have a massive impact on the security posture of your cloud environments.
From there, you should map the relationships between identities and the systems they access. This is an important part of understanding your attack surface. Cloud-native application protection platforms (CNAPPs) are designed to help with this. Having a strong CNAPP platform gives the security team the ability to detect abnormal behavior around a particular identity and detect when configurations start to drift.
Align Your Different Teams
Once you have the identities and the relationships mapped out, you need to tie them to vulnerabilities and misconfigurations to determine where you are most vulnerable and start quantifying the applied risk. You can’t create an effective remediation strategy without that.
But data and strategy will take you only so far. Teams tend to operate in silos, and each follows prioritization actions based on the specific software they are using, without communication with other teams or alignment on a holistic vision for minimizing risk. Because not every attack surface is the same, you need to structure the organization so that different skill sets can take mitigative action based on the variables specific to their environment.
When teams are coupled more closely, organizational risk drops. Let’s say you have a cross-site scripting vulnerability in one of your Web applications. Wouldn’t it make sense to prioritize any security or configuration issue associated with the infrastructure running that application? The inverse is also true. Does it not make more sense to address the vulnerability that is running in production or sitting on the Internet versus a vulnerability running in a dev environment with no chance of exploitation?
A large part of the reason security teams work in these silos is because the vendor landscape has kind of forced them to work this way. Until recently, there hasn’t been a way to do the things I’m proposing here — at least not for anyone but the 1% of organizations that have vast security budgets and built in-house tools and teams.
To sum up, protecting identities — cloud and otherwise — requires adopting a mindset shift from compliance to a holistic security, applied risk approach that involves gaining visibility into your cloud infrastructure with CNAPP and aligning different teams on prioritizing remediation.