How to limit the cloud security blast radius of credential attacks
Explore how the security blast radius concept, which has admins evaluating how to assess and limit the damage of a threat, can be applied to cloud identity and access management.
Security teams today must accept the fact that the cloud isn't an inherently safe place to do business. Cloud environments face many threats, from account hijacking to denial of service. It's the job of security teams everywhere to protect cloud-based assets and limit the potential damage of any attacks that may occur.
As evidenced by many notable hacks, the effects of an attack on a single user's credentials reach far beyond the targeted victim, often affecting the entire organization and its customers.
In the SANS 2019 Cloud Security Survey, the major issues respondents experienced centered on basic hygiene and configuration, such as lack of skills, poor configuration of rapid deployments and insecure APIs. The majority of cloud-based attacks reported by respondents underscore the apparent immaturity in defending the cloud, and nearly half of the attacks involved account or credential hijacking. This, along with the 38% who reported privileged user abuse, indicates organizations might not be protecting credentials and privileged user access as well as they should.
Security teams must implement new strategies to prevent and counter attacks on cloud resources. One core security concept being readily adopted by DevOps teams is blast radius, considering the amount of damage that could be caused if something goes wrong -- for example, the effects of an account or server getting hacked or a component failing.
By asking 'what if' for potential cloud threats, teams can properly prepare to combat them and limit the threat's blast radius.
Security teams would be wise to add the blast radius concept to their arsenal. By asking "what if" for potential cloud threats, teams can properly prepare for them and limit the threat's blast radius.
How to limit cloud security blast radius
The blast radius concept involves designing your cloud security model in such a way that it limits the damage any one issue could cause. Do this and you will find yourself stressing out much less while deploying cloud technologies.
As blast radius is being used by application and operations teams, it's a sound -- and familiar -- concept to use when implementing access controls and design models.
An example of blast radius and its limitation might look like this:
What if a cloud identity or Azure Active Directory account gets compromised?
Attackers could move laterally, access sensitive data, pose as this user, etc.
Limit by using multifactor authentication, logging and monitoring, creating strict access controls.
Another example could be the following:
What if a misconfigured network security group is implemented in Azure?
Attackers could move laterally, access network services and systems that should not be visible, etc.
Limit by auditing network security group rules, using infrastructure-as-code templates and host-based security tools.
One of the more innovative new cloud architecture and design ideas that emerged in recent years to control access and limit the security blast radius is the use of multiple accounts. Accounts can be created for a number of different groups within any major cloud environment. Common account roles include developers, operations teams, business groups, such as sales and marketing, and a dedicated security account. In such a setup, all logs from every other account can be forwarded to the security account logging repository to tightly control how logs and events are collected and managed. Central user accounts can be set up for initial cloud access as well, and then all assets are in different accounts that have specific roles provisioned to them.
AWS Landing Zone, a service delivered by architects or service providers, helps set up multi-account environments, and the AWS Control Tower service, released at AWS re:Invent 2018, automates Landing Zone behavior. Microsoft Azure uses a slightly different model, with a single account and different subscriptions that are implemented for various functions.
In addition to a multi-account or multisubscription strategy, companies need strong access controls to effectively secure who can do what and from where. The who could be a user or app identity or systems or subnets within the environment. Many cloud access management strategies are starting to revolve around the idea of object-oriented security, also referred to as microsegmentation or zero-trust design. Whatever you choose to call it, the two most critical elements of this strategy will be identity and access management and network access and segmentation design.
For many organizations, designing access controls will often encompass a blend of different security mechanisms. This is an area that is evolving quickly, so security teams should pay careful attention to both the market and open source communities. This could include prudent use of network access controls and extensive logging to monitor any changes to the environment, which can also help limit the cloud security blast radius.
