External threats are easy to comprehend for people outside of the security team, and therefore over-represented in business literature: a ‘hacker’ (portrayed as a dark silhouette behind a computer with a hoodie on, for some reason) bangs on the keyboard, probing your defenses until they find some sensitive info that was left public via misconfiguration. There are sometimes sensitive data in that public bucket, but usually that’s just a starting point to abuse an internal access policy failure. In the public cloud, there are many external threats, but internal threats account for the majority of successful data exposures – and the most costly attacks.
It’s time we switched perception to match reality. The concept of on-premise internal threats weren’t portable to the cloud, as the concept of an “identity” improperly accessing sensitive data has changed entirely. An ‘identity’ is no longer a user or an IT service account, but a set of permissions that can be accessed by many entities several different ways – thanks to permission chaining, development oversights, or privilege escalation capabilities. This can start with a bucket mistakenly left public, but the real damage is done when internal access controls aren’t defending against the abuse of these capabilities.
This requires a different approach to internal access – namely, a Least Access policy becomes paramount for data protection. In this session, we’ll demonstrate typical internal threats in AWS and how they abuse poor identity policies to expose sensitive data. We’ll also cover:
- The volume and diversity of internal threats to sensitive data access
- How some typical paths for an internal threat that will pass typical auditing and data classification policies
- How these threats bypass IAM and other explicit permission monitoring
- Why a Least Access policy is the most important guard against internal threat, and how to implement one
