Trustle: 82% breaches tied to identity

Cloud security keeps getting described like a malware problem. But the thing that actually breaks first, a lot of the time, is identity — who can access what, for how long, and with which inherited permissions. That is the point Trustle has been pushing in recent posts and marketing, and the broad shape is real even if the headline number needs care. The cleanest public benchmark is still Verizon’s 2024 DBIR: 68% of breaches involved a human element. Trustle’s 82% figure points to cloud data exposure, not the exact same category. (verizon.com) ### So what is the story here? Basically, identity has become the control plane for modern infrastructure. In cloud environments, access is stitched together from IAM roles, service accounts, federated logins, API keys, CI/CD pipelines, and machine-to-machine permissions. That means a breach often does not need a dramatic “hack” in the movie sense. An attacker just needs one usable path into an over-privileged identity. (trustle.com) ### Why does the 82% number need unpacking? Because it is easy to blur different breach statistics into one scary sentence. Verizon’s number is about breaches with a human element. Trustle’s cited stat says 82% of breaches now involve data stored in the cloud. Those are related ideas, but they are not interchangeable. One measures how breaches happen. The other measures where affected data lived. (trustle.com)ence even when the underlying warning is valid. (verizon.com) ### Where does SSRF fit into this? SSRF is one of the cleanest examples of how a plain web flaw turns into an identity incident. The bug lets an attacker trick a server into making requests on the attacker’s behalf. In cloud setups, that can mean requests to internal services the outside world cannot normally reach — especially metadata endpoint(verizon.com)rget. (cheatsheetseries.owasp.org) ### Why are metadata services such a big deal? Because they can expose the keys to the kingdom — or at least the keys to one workload’s kingdom. On AWS, an EC2 instance with an attached IAM role can retrieve temporary security credentials from the Instance Metadata Service. AWS warns that software making HTTP calls on a worklo(cheatsheetseries.owasp.org)heft becomes lateral movement. (docs.aws.amazon.com) ### Doesn’t AWS already defend against this? Partly. AWS added IMDSv2 as a defense-in-depth control. It requires a session token before metadata can be fetched, which helps block some SSRF paths. But the catch is that “some” is not “all.” If the workload is still over-privileged, or if older settings remain in place, or if the app can still(docs.aws.amazon.com)o not replace least privilege. (docs.aws.amazon.com) ### Why is least privilege so hard in practice? Because permissions only grow. Teams ship fast, people change jobs, contractors get added, services get chained together, and nobody wants to break production by removing access. Trustle’s whole pitch around entitlement creep lands here. Cloud estates are now hybrid and multi-cloud by default, (docs.aws.amazon.com) (trustle.com) ### What should teams actually do? Start with lifecycle control, not slogans. Inventory human and machine identities. Cut standing privileges. Use just-in-time access for sensitive roles. Enforce least privilege on workload identities, not just employees. Lock down metadata access paths and require IMDSv2 where AWS is involved. And treat every SSRF bug like a possible credential exposure event, not just a quirky web vuln. (docs.aws.amazon.com) ### Bottom line? The interesting part of this story is not that identity matters — everyone says that now. It is that cloud breaches increasingly look like permission failures wearing other costumes. Sometimes the first bug is SSRF. Sometimes it is a leaked token. But the real damage usually comes from what that identity was allowed to do next. (verizon.com)