Demystifying Zero Trust for Government

In Home Affairs recent publication of the 2023-2030 Australian Cyber Security Strategy, they have stated “We will also draw on internationally recognised approaches to zero trust, aiming to develop a whole-of-government zero trust culture.” Further to this, in 2022 the Australian Cyber Security Centre (ACSC) released an update to the gateway guidance package that included adoption of the tenets of Zero Trust as a directive, as well as link to the publication for further information. A zero-trust initiative is being taken seriously by the Australian Government as part of the long-term strategy, its key to understand why zero trust and its relevance in a security architecture.

The Zero Trust framework derives from a principle of “Never trust, Always verify”; Building upon the assumption that risk is an inherent factor both inside and outside the network. Zero Trust is becoming a popular buzzword within the industry, the term “Zero Trust” was popularized by John Kindervag in 2010, John worked at Forrester as a Research Analyst. John’s concept was that an organization should not extend inherent trust to anything inside or outside its perimeters. Born from this concept was the zero trust architecture, whereby eliminating implicit trust and implementing strong identity and access management (IAM) controls, federal departments can authorize individuals, devices, and applications for access to organization’s systems and data.

The National Institute of Standards and Technology (NIST) in August 2020 released a zero-trust architecture publication that is the foundations of implementing a zero-trust architecture design. NIST is an organisation within the U.S Department of Commerce, their purpose is to drive innovation and industrial competitiveness with advancements in science, standards, and technology. This publication is referred to as NIST SP 800-207 and has key contributors such as Information Technology Laboratory, Stu2Labs, Department of Homeland Security. Whilst the publication is on a 10-year-old concept, the principles of how to incorporate this into a security network architecture is still valid and the key take-aways from this publication.

The tenets of zero trust are reflective in the Gateway Guidance Package and show characteristics within ASD’s release of the Essential 8 program for Maturity level 2+. It’s clear that the Essential 8 program is setting down the foundations to aid agencies into reaching a zero-trust architecture. The following principals are outlined in the NIST publication and are modelled as ideal goals rather than hard principles. Its key to acknowledge that not all principles need to be fully implemented in their purest form go a given strategy.

The tenets of zero trust are as follows:

1. All data sources and computing services are considered.

2. All communication is secured regardless of network location.

3. Access to individual enterprise resources is granted on a per-session basis.

4. Access to resources is determined by dynamic policy—including the observable state of client identity, application or service, and the requesting asset—and may include other behavioural and environmental attributes.

5. All owned and associated assets have their integrity and security postures measured by the enterprise.

6. All resource authentication and authorisation are dynamic and strictly enforced before access is allowed.

7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

The tenets focus is to be technology agnostic, and guidance rather than prescriptive – As each environment is unique in nature, the objective is to encourage teams to approach designs under the principles, not the rules. Applying these principles, the network is not considered an implicit trust zone, assets should always act if there is an existing threat within the network. No resource is inherently trusted either, every resource should have its security posture evaluated through a policy enforcement point (PEP). This evaluation should be continual for as long as the session lasts, subject credentials alone are not sufficient for device authentication to a resource. Remote enterprise subjects and assets cannot fully trust their local network and assume that their local network is compromised. All workflows regardless of location should be treated as the same security posture and apply the same principles as if they were within the internal network or not. All these tenets cannot be enforced within the data plane and needs to have a logical separated control plane that administrates the access of data within an environment. This is called the Policy Decision Point (PDP) where a Policy Administrator (PA) working in conjunction with a Policy Engine (PE) will provide the decision process to a PEP. The PEP acts as the enforcement to confirm whether a user and system can be trusted to access the required resource.

Whilst this is the fundamental technology concept, the working deployment model compromises of deeper technology ideals. Understanding and developing a sense of the trusted and untrusted zones within your corporate environment is a key comprehension to the implementation of the deployment models. The NIST publication continues to define the deployment models into their respective categories focusing on specific use-cases. Below we have outlined in a high-level summary these deployment models and where they play their role within an environment.

Deployment Models:

The Device Agent/Gateway model typically is seen to be the foundation approach with it being closely aligned environments that have adopted a cloud first approach or have a hybrid cloud strategy. The Enclave model follows on from the Device Agent model however is signalling a more bespoke deployment where the resources are held within a private cloud or data centre. Resources portal model has a separate approach and reduced security visibility due to the lack of steering agent on the device, additionally the gateway portal is seen to be a cloud-based interface and publicly exposed to the internet.

1. Device Agent/Gateway Model

The device agent/gateway model is closest aligned to what is traditionally available in the market via the Security Access Services Edge solutions such as Netskope. In a typical scenario, the user with an enterprise-issued laptop attempts to connect to an enterprise resource ie. Application or Database. The local agent on the device forwards the request to the PA and the PE evaluates the request. If the request is authorized, the PA creates a communication channel between the agent and access gateway Infront of the data resource. The connection is terminated once the workflow is completed or by the PA when a security event occurs ie. Session Time-out, Failure to re-authenticate. This model is seen as the most popular as this system reflects many enterprise environments that have already transitioned to the cloud. In majority of situations, the Cloud gateway edge will be where the PA creates the channel of communication to, and the gateway will act as the PEP.

2. Enclave Gateway Model

The Enclave Gateway Model is closest aligned to the traditional Secure Internet Gateway model where resources are held behind a data centre or utilising a private cloud environment that resides behind in a resource enclave. This model is similar premise but a variation to the Device agent model where resources reside in a resource enclave together rather than separated. Its entirely possible that this deployment runs along-side a Device Agent model where legacy or aging applications within the environment live behind the gateway on a complete private cloud solution. The main hindrance is that the gateway protects a collection of resources and may not be able to protect each resource individually. Further system development will need to occur between the gateway and individual resources to create the micro segmentation and isolation of resources.

3. Resource Portal Model

The Resources Portal Model utilises a gateway portal as the PEP and doesn’t utilise any steering agent to establish a secure connection from the policy administrator. The PA still authorises the access with the PE, however this model lacks visibility over the user as the missing agent on the users device is not required. This model only scans and analyses assets and devices once they connected to the gateway portal and may not be able to continuously monitor them for any security issues such as malware, unpatched vulnerabilities, and appropriate configurations. The portal is considered internet facing and can be at the determent of various internet facing attacks such as DoS.

Zero Trust shouldn’t be treated as a simple adjustment but rather the next evolution of the step to securing the network. The architecture itself requires an agency to have detailed knowledge of its assets, subjects, and business processes in which the PE will evaluate resource requests. Incomplete understand will often lead to failure in the implementation and thus PE rejects requests due to insufficient understanding from the information it has been provided. Zero trust architecture doesn’t have to be a one size fit all solution but rather can be micro-deployments on resource locations and a mixture of deployment methods that best fit the departments ICT Systems.