5 mins to read
The challenge of protecting data lies not in the security of the cloud itself, but the policies and technologies used by organizations to secure it, noted industry Analyst, Gartner. In fact, Gartner predicts that through 2025, 99% of cloud security failures will be the customer’s fault. It can sound harsh, but it’s meant to grab your attention. The good news is, this accountability means cloud customers have direct control over the severity of their own security risk.
It’s difficult to calculate cloud risk if you don’t know what’s in your cloud, where your data lives, and who has access to it. All in all, you need visibility. That being said, one of the most important things you can do when building a cloud risk management strategy is to determine your blast radius.
What is a Blast Radius in Cloud Security?
A blast radius is a way of measuring the total impact of a potential security event. For example, imagine an intruder worms their way into a cloud server. In this scenario, the blast radius would be the overall amount of damage that the intruder could inflict after gaining access into the server. Is this breach contained to this one server? Or can the attacker move laterally through your cloud? Maybe just one of your employee’s credentials are compromised, but this employee holds a cloud identity that is overpermissioned. Quickly, this one employee’s credential compromise has repercussions far beyond the individual.
The cloud’s unique scale, scope, and complexity makes a blast radius much larger and more significant than on-premise structures. Just simply asking the ‘what if’ question can help your team discover cloud risk and better prepare for future security incidents.
At this point in time, it’s not an ‘if’, but a ‘when’ regarding vulnerabilities, network failures, misconfigurations, and other ways into your environment. However, in the cloud, the concern should less so be ‘can they get in?’ and more so be ‘what can they do if they get in?’ While cloud providers often advertise strong security and compliance measures, security is almost always a shared responsibility. The reality is organizations are responsible for protecting their own cloud, and mitigating the blast radius of potential incidents is a step towards that.
How to Measure Your Blast Radius
As AWS VP and Distinguished Engineer Peter Vosshall explains, failure isn’t binary. Rather, there is always a degree of impact to consider. In this light, there is no single way to determine the blast radius. It turns out there are a few different ways to approach the topic and measure blast radius. Some areas to consider:
Customer Impact
One of the most obvious ways of measuring blast radius is by customer impact. Your blast radius can describe the overall number of customer accounts that are at risk from a security incident.
Functionality
Another way to measure blast radius is to think about account functionality or the individual processes that may be impacted during an attack.
Location
You can also determine blast radius by location. A small radius may include a compromised server or rack. In a larger attack, a blast radius could even include an entire region.
How to Reduce Your Blast Radius
Ideally, companies should plan ahead to limit the amount of damage that a bad actor could cause. As Murphy’s Law goes, anything that can go wrong will go wrong; it’s only a matter of time. That being a case, you should anticipate that your cloud environments will be compromised eventually. Don’t wait until after you detect a data breach to spring into action. At that point, it could be too late. By taking a proactive stance to reduce your attack surface with strong security measures, you can limit the spread of the attack. Let’s review some steps:
Isolate Cloud Accounts
One of the most effective ways of limiting your blast radius is to isolate your cloud accounts, or use a multi-account strategy. Create different accounts for developers, security teams, operations, and business units, and grant access only as needed. Multi-account strategies mitigate lateral movement and reduce blast radius. When accounts (and therefore workloads, resources, identities, and permissions) are linked, the blast radius can be massive, stretching across the entire organization.
Maintain Least Privilege
Part of reducing your attack surface is minimizing an identity’s effective permissions (their true scope of abilities.) One way to minimize permissions is work towards Least Privilege. This concept entails granting the bare minimum privileges needed for an identity to complete its job function. Anything unnecessary or unused should be stripped. Do not offer broad strokes of privilege for convenience. This is one of the most impactful efforts your organization can make to reduce blast radius in the event of an incident. Consider a workload with a vulnerability on it. If that Virtual Machine for example, through several degrees of separation somehow has permission to ‘edit’ everything in a Staging server, your organization is far worse off then if the VM was at Least Privilege.
Maintain Least Access
Similarly, but different, there is Least Access. Least Access theoretically starts at the data, and works outwards to evaluate what and who can access your most critical assets. At its core: Least Access means data is restricted to only those who must access it. To achieve Least Access, your team will need to begin with an inventory of your data. Discover where your data is, what it is, and how important it is. This is data classification & tagging. It’ll help you sort your crowned jewels (and what needs the greatest protection.) This is a critical step enabling you to then determine what policies to apply to what data, so you can set up a sort of ‘trip-wire’ around data. The less access to your data, the smaller your blast radius.
Continuously Monitor
Continuous monitoring is needed to maintain both Least Privilege and Least Access. You should also have direct visibility into what normal access behavior looks like – a baseline – and what activity is taking place at all times. A security platform should be able to flag suspicious access activity or unwanted changes in access rights or permissions. For example, if someone logs into a server in the middle of the night from a country where you don’t do business, an alert should be immediately triggered, and predefined security actions should be automatically deployed — like temporarily shutting down the account and terminating user access.
Understanding Your Blast Radius With Sonrai Security
Knowing the potential blast radius of every vulnerability is the only way your team can prioritize what needs to be fixed first. Our critical context into how vulnerabilities tie back to identity and data risks is what fuels our prioritization insights — so you fix what would hurt your business the most, first.
Read the latest news and insights
10.26.2022
In the early days of risk detection, if your security...
10.20.2022
If you’re not focused on identity and access controls,...
03.09.2022
Log4j: The Recap There is nothing in the cloud security...
