Identities

How does identity fit into the larger Zero Trust strategy?

Zero Trust identity is a way to grant access across the network in a granular fashion based on trustworthiness. Zero Trust starts with no access by default and then intelligently provides different levels of access to specific entities – whether it’s a user, an application, data or a device. And this access is provided based on pre-set rules. However, in order for this to work, organizations need to identify, without a doubt, exactly who is asking for access and what they plan on doing once they get it.

How can Zero Trust help assess an entity’s identity?

Zero Trust identity is more than just username, password and multi-factor authentication (MFA). You need another level of security checks to ensure that the person, application or device is who or what they say they are. This includes other clues such as device information, physical location and, ultimately, behavior.

Why can’t legacy identity tools provide this level of granularity?

Traditional identity tools were designed for hub and spoke models where a few entities outside a hardened firewall connected to the network through a VPN. All traffic would flow back to the data center where it could be monitored and policies would be applied. Organizations just had to authenticate the entity at the first touch and then not have to worry about monitoring or securing east-west traffic. Authenticating with a username, password and MFA worked well for this architecture.

However, we don’t live in that world anymore. In today’s highly distributed enterprise, users, applications, devices, and data are spread out across private data centers, public cloud infrastructures and Software as a Service (SaaS) platforms, and the network is too spread out, too complex, and too interconnected with third-party entities. A user may be able to gain initial access, then have unfettered access to the rest of the network. The inability to continually authenticate and restrict access on a granular level is a major security gap that threat actors are using with a high degree of success.

How can Zero Trust identity bridge this gap?

It’s all about assessing how certain you are of an entity’s identity and then using that assessment to provide or limit accessibility. For example, a known user could log in to an application with the correct credentials and pass MFA. However, what if the user has been determined to be located in a country such as Albania. Not only is that a strange location for this particular user to be located in, it’s a known hotbed of hacker activity. In addition, the user, a marketing executive, is trying to access the payroll app – again, an abnormal behavior.

Do you provide access or not? With Zero Trust identity you can apply policies that provide the authenticated user access to the application but limits him to read-only. This granular level of control protects the application from potentially malicious activity without disrupting the user’s productivity – just in case the user really does have a legitimate reason for accessing payroll from Albania. Zero Trust identity allows you to assess the level of trustworthiness, provide granular accessibility, and apply these policies globally.

What are the components of Zero Trust identity?

Start with a catalog of all entities

You can’t secure what you don’t know. Any Zero Trust identity strategy starts with cataloging your applications so you know where they sit in the network and what users need access. You can then define levels of accessibility to determine who gets full access, who gets read-only and whether users can get upload or download permissions.

Set identity policies

Once you know what you have, you can bake levels of control into your Zero Trust strategy. It’s almost like calculating a risk score. In the above example, the user provided the correct username and password and passed MFA but was exhibiting abnormal behavior from a risky location. The result is read-only with no ability to download or exfiltrate the data. Zero Trust policies allow you to set these various levels of security based on identity and pre-set rules and apply them globally.

Clientless by default

Once you’ve cataloged your network and set identity policies to determine trustworthiness and the corresponding accessibility levels, it’s time to actually connect users without exposing applications to malicious threats. You can do this with a client – such as a VPN – or, ideally, in a clientless architecture. Not requiring a piece of software to be installed on a device reduces IT overhead and allows you to extend Zero Trust identity to unmanaged devices – such as a partner, supplier and contractor or an employee’s personal device.

On the application side, you need to deploy a connector to grant access to trusted users. These connectors reside wherever the application sits – whether it’s in a data center or the public cloud – and act as a gateway to allow access for authenticated users. However, today’s distributed enterprise requires direct user to application access across the public Internet, requiring applications to be publicly discoverable. Closing this critical security gap requires a central control point through which all traffic flows that provides a private tunnel over the Internet that is only accessible to authenticated users.

Why is Menlo Security in a good position to deliver on the promise of Zero Trust identity?

Menlo Security is built on an Isolation Core™ – providing a ubiquitous, abstracted layer in the cloud through which all traffic flows. Everything goes through this abstracted layer in the cloud, giving administrators unparalleled visibility and control into security without impacting the native user experience. In addition, Menlo starts with a clientless first approach, making it easier for IT staff and more intuitive for end users.