Get your Blast Radius cloud strategy right.
As in Gartner:
“Through 2025, 90% of the organizations that fail to control public cloud use will inappropriately share sensitive data.”
“Through 2024, the majority of enterprises will continue to struggle with appropriately measuring cloud security risks.”
“Through 2025, 99% of cloud security failures will be the customer’s fault.”
As far as your cloud seems to be a black box, where IAM, data access control and configuration control lack visibility, risk analysis and calculation becomes difficult. You cannot protect when you don’t know. In addtion, although CSPs implement good security and compliance practices, in the end your assets are yours. So it’s always a shared responsabilty. If you check the most common cloud security challenges, it certainly smells the aroma of tenant responsability. But failure comes in degrees, and working in “assumption of breach”, you need to take a proactive approach to reduce your attack surface and limit the spread of the attack. That, in a nutshell, is calculating and reducing your Blast Radius -what might happen if everything goes south and what can we do BEFOREHAND to minimize the impact-.
Calculating your Blast Radius
· Processes: Analyze which processes and accounts could be affected during an attack, and how, in terms of functionality
· Technology: Analyze which systems could be impacted and where they are located. Do you have geographical redundancy? Do you have a concentration of systems in one location?
· People: Measure your customer impact in sheer numerical terms. How many accounts might be at risk from a single attack?
Reducing your Blast Radius
Account isolation and need-to-use basis: Identity, Authentication and Authorization make the new perimeter so your access control must implement role-segregated accounts to minimize the risk of lateral movement and reduce the scope of the attack. A multi-account or multisubscription strategy, can be easily -more or less- implemented where all role accounts (Developer, Business, Admins,…) logs are forwarded to a dedicated security account logging repository.
Context and behavioural approach to authentication: A seemingly legit login might not be so, if comes from an impossible location or on an ungodly access time. In that case, a predefined security response should be triggered, blocking the suspicious logging attempt and related account. Of course, some sort multifactor authentication is a must have.
Object-oriented security and architecture: a zero-trust design with continuous authentication controls, infrastructure-as-code provisioning and host-based security tools; complement each other. The basics should include network segmentation to control and compartimentalize the traffic flow.
Relentless Monitoring: Visibility is the name of the game. However, it’s not -only- about logging, a real-time activity analysis is needed. There is where ML and IA tools come handy automating detection and response.
For the rest, as I always say, moving from on-premise to cloud doesn’t excuse the fundamentals, such as a well tested contingency plan, a vigilant incident response and backups.
In the end, Blast Radius is a mindframe that relates to the good old practice of evaluating and prioritizing vulnerabilities based on their potential impact to the business, so cybersecurity in terms of risk as usual, but it brings a fresh approach to it.
