Zero Trust Strategy: Part 2 Identity

An Enterprise-wide Identity System has two fundamental requirements:

The good news is that this can be easily accomplished in most existing environments, especially if you have a Microsoft Windows Domain. We’ll take a look at some examples in just a second, but first let’s make sure we understand the specifications. Simply having a Windows Domain doesn’t check the box – you actually have to turn on the required security controls.

Let’s look at an example. Alice, a domain administrator, logs in at 7pm Eastern Standard Time to make some user modifications. Consider these questions:

• Does Alice normally work nights? 

• Is Alice based in California, making it 4pm local time for her? 

• Does Alice’s role involve her making user modifications?

The ZTA concepts go beyond simply assigning roles. You need the context to understand the different types of access, verify the identity when necessary, and retain the ability to restrict access if certain criteria is not met.

An example I love to talk about involves badging systems. Most government spaces require a physical badge to access various buildings or offices. This badge system maintains a log of user activity including timestamps, though rarely is this information used by security teams to check for anomalies in user behavior. Through simple automation and connecting the required systems, a check can be performed to validate a user’s physical location and correspond it with their standard behavior on the network. 

There are two other considerations when looking at an Identity System: Single Sign-on (SSO) and the integration of non-graphical user interfaces. Let’s reference the memo:

There are many SSO solutions out there. What works for your organization will be highly dependent on what types of systems you have in place, and what type of architecture you have (on premises, virtual, cloud, etc.). For instance, Microsoft maintains their own SSO solutions, but Okta is a vendor that provides a solution for many organizations having a distributed non-Windows domain environment.

And you can’t forget about non-graphical systems, scripts, and command-line tools! A common example of this can be seen where there are proper controls setup in a Windows domain, but within that network is a Linux server hosting some application. Attackers can use this to pivot and bypass existing controls due to it having more relaxed restrictions. Implementing a solution for this may require a deeper technical engineering plan, but is nonetheless important.