Demystifying zero trust for government

As zero trust becomes more central to ICT environments, it needs to be considered not just as an adjustment but the next evolution of securing vital networks.

In Home Affairs’ recent publication of the 2023–2030 Australian Cyber Security Strategy, now moving towards becoming the nation’s first Cyber Security Act, it states: “We will also draw on internationally recognised approaches to zero trust, aiming to develop a whole-of-government zero trust culture.”

With these initiatives being taken seriously by the government as part of its broader cyber strategy, it’s important to understand zero trust and its relevance in a government agency security architecture and posture.

The zero-trust framework derives from the principle of ‘never trust, always verify’. It builds on the assumption that risk is inherent both inside and outside an agency’s network.

Zero trust’s architecture eliminates implicit trust and implements strong identity and access management (IAM) controls, so that federal departments and other government agencies can authorise individuals, devices and applications before granting access to systems and data.

In Australia, the tenets of zero trust are reflected in the Australian Signals Directorate’s (ASD) Gateway Security Guidance Package¹, designed to assist organisations to make informed risk-based decisions when designing, procuring, operating, maintaining or disposing of gateway services, the systems that control data flow between networks.

Zero trust is also covered in the Essential Eight set of mitigation strategies for the higher maturity levels two and three. Overseas, the US’s National Institute of Standards and Technology (NIST) has released a zero-trust architecture publication² and set of principles to which the ASD and Australian Government align:

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 aim is for these tenets to be technology agnostic, and to be guidance rather than prescriptive rules. This reflects that each environment is unique in nature, and in a government context, the threats, requirements and risks vary from agency to agency.

But applying the principles means that ICT assets should always act as if there is an existing threat within the network. No resource (source of data) is inherently trusted either; each should have its security posture evaluated throughout every session through a policy enforcement point (PEP).

This applies remotely too: remote enterprise subjects (users and devices) and assets (devices connected to the network) can’t fully trust their local network and should assume it’s compromised. All workflows, regardless of location, should be treated the same in terms of security posture and apply principles as if they were within the internal network or not.

It’s also important to understand that these tenets cannot be enforced at the data layer alone and require a separated control pane that administrates the access of data within a specific environment.

Deployment models

While the tenets are the fundamental technology concept, there are deeper deployment models government ICT departments need to understand to develop a sense of the trusted and untrusted zones within their environment: the Device Agent/Gateway model, the Enclave Gateway model and the Resources Portal model.

Device Agent/Gateway model

The Device Agent/Gateway model is typically the foundation approach as it closely aligns with environments that have a cloud-first approach or a hybrid cloud strategy. This works well for government agency environments that are typically at some point of transition into the cloud, with many having remote working environments in place. In this model, the PEP is split into two parts, one on an asset and one in front of a resource.

To give a practical example of how the most likely relevant Device Agent/Gateway model works, a user with a government-issued laptop attempts to connect to an enterprise resource such as an application or database. The local agent on the device forwards the request to the policy administrator, and the policy engine software evaluates the request.

If authorised, the administrator creates a communication channel between the agent and access gateway. The connection is terminated once the workflow is completed or by the administrator when a security event occurs, eg, session time-out or failure to re-authenticate. This model is popular as the system reflects many enterprise environments that have already transitioned or are transitioning to the cloud.

Enclave Gateway model

The Enclave Gateway model follows on from the Device Agent/Gateway model. It signals a more bespoke deployment where the resources are held within a private cloud or data centre.

This model is closest in alignment to the traditional Secure Internet Gateway (SIG) model where resources are held in a data centre or use a private cloud environment. It is similar but varies from the Device Agent/Gateway model in that resources reside in a resource enclave together rather than separated.

It’s also possible that this deployment runs alongside a Device Agent/Gateway model, where legacy or ageing applications within the environment live behind the gateway on a complete private cloud system.

The main hindrance with this model is that the gateway protects a collection of resources and may not be able to individually protect each resource. Further system development needs to happen between the gateway and individual resources to create micro-segmentation — zones within data centres and cloud environments to isolate workloads.

Resources Portal model

The Resources Portal model has a separate approach and reduced security visibility due to the lack of a steering agent on the device. Further, the gateway portal is seen to be a cloud-based interface and publicly exposed to the internet.

This model uses a gateway portal as the PEP and doesn’t use any steering agent to establish a secure connection from the policy administrator. The administrator still authorises the access with the policy engine; however, this model lacks visibility over the user as the agent on the user’s device is not required.

The Resources model only scans and analyses assets and devices once they’re connected to the gateway portal and may not be able to continuously monitor them for security issues such as malware, unpatched vulnerabilities and appropriate configurations. The portal is considered internet-facing and can also be a deterrent for various internet-facing attacks such as a denial-of-service (DoS) attack.

Zero trust: the next evolution

As the government sets the scene for zero-trust principles, architecture and culture to become more central to department’s ICT and security environments, it needs to be considered not just as an adjustment, but the next evolution of securing these vital networks.

There are also a number of challenges and procedures to address within government to ready for the zero trust shift, including migrating policies to zero trust platforms, providing support for legacy systems, bringing skilled people in amid a cyber talent shortage, and maintaining Essential Eight maturity level two.

Zero trust shouldn’t be viewed as a one-size-fits-all solution either — it can be implemented iteratively through a mixture of deployment methods to best suit individual agencies. This will help to ensure zero trust works for the organisation, people and data it’s ultimately protecting.

^{1. Australian Cyber Security Centre 2022, Gateway Security Guidance Package: Overview, <<https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/system-hardening-and-administration/gateway-hardening/gateway-security-guidance-package-overview>>}

^{2. National Institute of Standards and Technology 2020, Zero trust Architecture, <<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf>>}

*James Rabey is a principal consultant with Macquarie Government, an Australian provider of cloud and security services for Australian government agencies. He has more than two decades of consultancy, marketing and management experience across a range of leading Australian and international technology companies.

Top image credit: iStock.com/Olivier Le Moal