The Six Elements of the Zero Trust Security Model

Below is a graphical representation of the 6 elements of the Zero Trust Security model that we discussed above. Here I am breaking devices into corporate or managed devices and unmanaged devices, as these are the 2 main categories of devices. I am also added some of the characteristic or capabilities to the elements on the right, to show the various components and their sub-elements.

The one thing missing from the 6 elements is the policy engine that makes the decisions, and that is central to the Zero Trust model. The policy engine uses information about the devices and IDs and intelligence about threats within and outside the enterprise, as well as a set of policies that the CISO and security teams have defined. All of this is used to make the allow/disallow decision.

So, if we now start the flow, we see someone signing into a device using their credentials (userid/password, face, fingerprint, Multi-Factor authentication, etc.). When a request for access to any of the resources (elements) on the right is made, the device sends that request to the policy engine. The request contains the credentials that were used to make the request as well as information about the device.

So, what is important to know about the device? Well, some important things are:

• Is it managed or not?
• What is its IP address?
• Is the device secure or not?
• Who is the device registered to?

The combination of the Identity and device information is then examined by the policy engine using historical intelligence about the Identity, device, etc. and the policies that have been defined by the organization. If access is allowed, the request is passed through, if not, it is returned.

When the request is passed through by the policy engine, the elements on the left use various techniques (in the blue boxes) to control/limit access to the objects ( and their sub-elements, in the grey boxes).

The data needs to be classified, labeled, and encrypted to keep it safe, and ensure only the right data is accessible by individual Identities.

Applications use adaptive access techniques so that even if you can access an app, if it access data, you can only see the data you are supposed to see, not all of it just because you are using the application.

And, the systems and other infrastructure also need to check credentials at the time of access and also whenever the Identity tries to run anything. These checks should also be using the dynamically updated threat intelligence like the policy engine for this purpose.

The first basic principle of Zero Trust is to authenticate and verify access to all resources, every time. Each time a user accesses a file share, application, or cloud storage device, re-authenticate that user’s access to the resource in question. You must assume that every attempt at access on your network is a threat until confirmed otherwise, regardless of location of access or hosting model. To implement this set of controls, remote authentication and access protocols, perimeter security, and network access controls. With monitoring and data security analytics in place, you can tell the difference between a normal login or a compromised user account. You will know that a ransomware attack is in progress or if a malicious insider is trying to upload files to their cloud drive.

In my next blog I will step through an example of how this all works, and why you need to have visibility and analytics as well as orchestration and automation to truly have a Zero Trust system.