Zero Trust

No longer just a buzzword to be banded about boardrooms to make it sound like someone has a grip on security, Zero Trust Networks are becoming a reality. We were given the chance to look at Zero Trust and what it would take to implement it.

The Brief

The client had fantastic security. Users had access to the data they needed to fulfil the mission and security was always at the heart of any solution development. However, the amount of data and overwhelming user complexity was becoming a management nightmare. We were to investigate Zero Trust Networks (ZTN) and come up with a recommendation. 


Speaking to a large number of stakeholders, such as Product Owners, security architects, solution architects, and security management, we uncovered a logistical nightmare when it came to allocating user access to apps and data. There appeared to be two levels of security. First, access to the app was determined, second, access to the relevant parts of the app (and therefore the data) was determined. The latter sometimes set up in the app itself using the app’s own internal security mechanisms. Thousands of Active Directory groups, complex nesting, PKI certificate allocation, as well as hundreds of internal app security, all added up to a bloated, inefficient, and complicated security arrangement. Couple this with separate management of firewalls and proxies, lead to millions of combinations of access.


We began with getting to grips with ZTN principles. As technology wasn’t part of the brief, we turned away from any of the ‘magic bullet’ solutions, because ZTN isn’t about a single product; it’s a completely new way of thinking about security. Choosing a partner would come later. In a nutshell, ZTN is about protecting your internal systems as though they were on the Internet. Treat everything as hostile, and authenticate at every step. Obviously ZTN is vastly more than that, but it was a good enough foundation to begin looking at how it can help the organisation.

Taking a common sense approach to the problem, we began looking at what would happen if an attacker did make it into the internal network. Every organisation will believe their security is world-class and nothing can get in. But they would be wrong How many large corporations have been subject to ransomware attacks? The NHS was one victim for example. Surely the NHS would have ‘world-class’ security on it’s networks? The main problem with traditional security is it relies on soft bodies in hard shells. But any mollusc will realise very quickly that once the shell is breached, the body is doomed.

The approach we took at determining if ZTN is for the organisation is looking at the potential for breach. Firewalls with over ten thousand rules on them are pointless. The ‘Swiss Cheese’ approach leaves the internal network open to attack immediately. Why so many? Connection to third-party networks are usually to blame. But as the third party changes something that then breaks the connection, a change request is raised for an engineer to add the new rule, but not to take off the old one.

Perimeter firewalls are only the start. Once and attacker gets a foothold, we looked at the potential for sideways movement. A server with unused services and open ports for example allows the attacker to get onto it and begin to exploit the data. Soon, like a scene from Resident Evil, the attack propagates through the data centre. We were quickly able to establish sideways movement would be a problem.

The next area of interest was the users and devices. A simple question like ‘How many devices do you have’ couldn’t be answered with any degree of accuracy. We weren’t just concentrating on user devices, but servers, in-band managed networks devices, in fact everything connected to the network. We realised there was much to do.

Apps are another area of concern. Web apps accessing back-end databases without any security is a great way of losing all your data. Once on the web server, an attacker can quickly get onto the database and extract all the data. There was also no logging of activity, apart from on the larger, more sensitive systems. An attacker on a compromised web server would go un-noticed until the data appears in the press.

This lead us to realise the organisation would benefit from ZTN. However, Provantage would not provide the solution alone. Our recommendations were:

  • Involve vendors to provide ZTN policies for their own technology
  • Establish a ZTN taskforce to provide co-ordination between the vendors and in-house developers
  • Put ZTN at the heart of development
  • Make it a multi-vendor solution, with each providing their piece of the puzzle
  • Take notice of the lessons learned from Google (BeyondCorp) and Capital One’s experiences
  • Don’t try and reinvent the wheel – ZTN is new, but it is widespread and good practices are available
  • Make ZTN a priority and get a first draft of the policies signed off within three months

This then provided the baseline for a three-year initiative to improve and simplify security.


Simplified security

The resultant framework will vastly simplify the security of data and apps. Security anomalies can be quickly identified and addressed.

Alerting, not defending

ZTN turns security from being a complicated affair where every type of attack is mitigated in everything at a granular level, to prevent everything, allow based on trust.


Cloud-based operations become self-healing by adopting a more cattle approach to services. Potential for breach is reduced since all services are only a few hours old before they are refreshed. 

Better securty

Simplified security is better security. Using alerts to notify when something looks odd vastly reduces the setup overhead. Access is gained through trust and not by the configuration of dozens of groups.


Administrators spend less time configuring endless groups and firewall rules. They can be better utilised dealing with anomalies rather than trying to defend against everything up front.

It doesn’t matter how many users, apps, devices, or data sets there are, ZTN will scale out quite comfortably. There is no need any more to keep configuring endless groups and training administrators to keep on on of the complexities.

Using notification of anomalies makes it easier to react to incidents, repair the damage, and tweak policies. The exact location will be known and blast radius controlled.