October 24, 2019
The classic approach to defending a network was to put up perimeter defenses, typically a firewall with some form of intrusion prevention/detection (IPS/IDS) system.
It’s an approach that worked for a while when there was a clear delineation between those inside and those outside the network. For remote workers, tunneling a hole through the firewall with a VPN brought them inside and treated them as insiders with complete access to … everything.
In the modern IT environment, with remote workers, third-party vendors, distributed offices, mobile, and cloud deployments – the classic perimeter no longer exists. Instead, the fundamental unit of access in most cases is identity.
In the cloud, in particular, identity is everything.
With an identity, in the form of a username/password or access credential, a user or device can get access to service. In the hands of an attacker, that same identity grants the same access.
You’re no longer safe because you have a firewall, you have to account for what your identities can do.
Time and again, in breach after breach, the modern attack cycle, particularly in the cloud starts with identity. Attackers seek to get access to an identity, then pivot between resources, discovering credentials and other identities that get them more and more access to get what they want.
Identity in the cloud-native era is not just about a simple Microsoft ActiveDirectory environment anymore. In the cloud era, where APIs are the gatekeepers of access, identity is the entirety of the data plane, since it’s a network-less perimeter.
We used to think about what systems attackers could control and where they had points of presence on a network. Now we have to think about what identities they control and what those identities can be used for. Because the network isn’t a safe point anymore.
The API plane makes pivoting between things trivial. If you have control of the right identity, you can move into a compute instance. And if you can move into an instance that has control over another identity, you can move to whatever that identity does.
Attacks can now be network-less in a way that isn’t controlled by the network perimeter. You’re no longer safe because you have a firewall, you have to account for what your identities can do.
Trying to secure identities is no easy task. The best IT organizations have lots of logs and can potentially use that information for threat hunting to look for anomalous activity. Some organizations make use of User and Entity Behavior Analytics (UEBA) to look for outliers and potential identity misuse.
Another approach is what we do at Odo Security. In the Zero Trust model, identity is still important, but it’s not a skeleton key that always grants access. At every stage of a client or host connection, our zero trust model has a security boundary that ensures that a request is valid and authorized to proceed. Rather than relying on an implicit trust after the correct username and password, or access token has been provided, with zero trust by definition everything is untrusted and needs to be checked before granting access..
The Odo Security Zero Trust model provides controls for the identity-based perimeter that go beyond credentials. Providing a least privilege model where access is only granted for what is required, combined with the use of segmentation further minimizes the attack surface.
With Zero Trust, the risk from a data breach in which user identities are stolen can be reduced because the identities are not always trusted by default. In the identity based cloud-native world we live in, we have to ensure trust in identities to know that our credentials are only where we expect them to be and used for the expected purpose.
Identity is the new perimeter in the cloud-native world, ignoring that fact and simply allowing credentials without challenge or validation is just not a good practice and it’s one that could expose your organization to risk.