In the past, cyber defences used to focus on a ‘perimeter’ consisting of geographical proximity. Therefore, everything within the security perimeter was confined to the office building. Today, fewer employees are required to go to an office to work since they can access an organization’s assets through mobile devices and cloud software, regardless of where they are located. Unfortunately, this gives cyber criminals more entry points to collect and damage an organization’s assets. 

ZTA, developed by Forrester’s John Kindervag in 2010, is one of the best ways to secure any kind of cyber assets for most organizations. The basic principles of zero trust are:

• -        Assume network is always hostile.
• -        Assume internal/external threats are always present.
• -        Assume internal network is not sufficient to equal trusted.

As not all organizations looking to implement ZTA are doing so under the same circumstances, let’s look at the two different varieties of implementation:

• Pure ZTA creation – This is also known as a ‘greenfield’ approach. New companies without cybersecurity architecture or those seeking a makeover of their existing systems are effectively starting over from scratch. 
• Hybrid ZTA and perimeter system ­– More commonly, companies looking to incorporate ZTA into their cyberdefences will be integrating zero trust concepts into an existing perimeter-focused cybersecurity system. 

7 steps to implementing a Zero Trust Architecture 

Step 1: Identifying Actors

The first stem is establishing the actors (who) of your system. This entails knowing who your users are, who potential threats may be, etc. This involves a process of detailed recordkeeping and account management, including:

• -        All individual users and their characteristics
• -        All nonperson entities (NTE) and their functions
• -        All attributes and roles associated with every account

Step 2: Identifying Assets 

The second step is establishing the ‘what’ of your system. This requires you to develop and maintain a catalog of all individual resources of assets that are part of your system. This list includes, but is not limited to:

-        Enterprise owned hardware

Computers and laptops

Mobile devices, tables, etc.

All IoT devices (e.g. Belkin WeMo Smart Light Switch, Amazon Echo Plus Voice Controller, Google Home Voice Controller)

-        Unowned assets that regularly connect to enterprise resources

Employee devices

Client devices

Third-party devices

-        Digital artifacts

All software and applications

User accounts and relevant data (see above)

Certificates and other digital or virtual resources

Step 3: Identifying Processes

Completing the initial inventory means keeping track of all processes in your system. 

Companies may not be able to catalog all the information in Step 2, therefore it is important to set up a system that can efficiently scan a new asset and index it immediately. That way, your database adapts over time as assets are added, removed, or changed.

This requires not only identifying all the processes, but also categorizing and ranking them with respect to stakes and cybersecurity needs. Processes to be gauged in this manner include:

• -        Protocols
• -        Data flows
• -        Work flows
• -        Transactions
• -        Structured events

Step 4: Formulating Policies 

This step is where you move on to the establishment of rules and practices. It is therefore important to utilize the information gathered over the cataloguing stages to gauge the importance of a given actor, asset, or process to the overall ZTA scheme and the broader cybersecurity of the organization.

It is highly recommended to begin with smaller or lower-stake process or asset. For instance, an application used by a small and defined subset of users is preferable for first adoption than one used by all users.

Once the right process or asset is chosen, policies regarding specific cybersecurity needs and means can be drafted. 

The policies define:

• -        Which credentials or authenticating factors are appropriate for access
• -        What information is eligible for the algorithm calculating access approval

-        How the algorithm for access is to be calculated:

• Logistics of access approval and denial
• Priority and relevance of information
• Exceptional cases and exceptions

Step 5: Producing Solutions

The fifth step involves creating the solutions by putting into action all the data collection and policy planning. 

Here, you draft a list of viable solutions or deployments of ZTA to be used on one or more candidates identified in Step 4. These solutions are also guided by the policies outlined in Step 4. 

You must determine which solution to implement. Things to consider when choosing from your list of solutions include:

• -        Does the solution enable data collection analysis?
• -        Does it require installation of components?
• -        Does location impact its efficacy?

Once a solution is chosen, you materialize it through deployment. 

Step 6: Beginning Deployment and Monitoring 

The sixth step involves putting your solution in place, deploying it on and through the various components that make up your ZTA architecture for the selected candidate(s). Actual changes are finally implemented to your cyberdefence framework. 

It is highly recommended to have one or more trial runs before deploying the solution in full force. Initial hiccups are likely, such as 

-        The system may be overly cautious, not granting access where it should.

-        The system may be improperly lax, granting more access than it should. 

-        The system may no properly handle special cases.

This step is not complete until the deployment of ZTA components on the chosen candidates is fully deployed. Once complete, you will have successfully implemented ZTA. 

Step 7: Expanding the Framework

This last step requires you to return to the fourth step. Insights from your first run through steps five and six will guide your decisions as you return to Step 4. 

Once you decided that the initial ZTA deployment on chosen candidates is functional and stable, because: 

• -        you are monitoring the ZTA and loggin all traffic,
• -        changes and adjustments are few and minor, and
• -        operation involves little to no maintenance. 

At this point, your deployment is successful. Moving forward you need to identify a new round of candidates for ZTA deployment, then designing the plan – until you enable cybersecurity for the complete list of applications that require protection, it should include application, data and infrastructure in your model implementation.