desktop as a service – zero trust network access

That's a mouthful. Semantically the same as "VDI buster", DaaS ZTNA is the application of Zero Trust principles to ephemeral workstations in the Cloud.

The advantages are succinct and clear for the client (DaaS) and the server (on-premise or another Cloud) in this Zero Trust use case.

Cloud-based workstations have an increased risk of data exfiltration incidents due to the open nature of their Internet access. This can be mitigated to a large extent by ZTNA's business application identity-based verification requirement. Cloud (or on-premise) servers with access open from the Internet (so that Cloud-based, ephemeral workstations can connect) also face an increased risk of an attack from the exposure. This can be mitigated with ZTNA's requirement of hidden application visibility. In our exploration of this approach, with the DiscrimiNAT Firewall in context, we look at two other dimensions besides just the pillars of ZTNA: Multi-Cloud and Developer Experience.

Multi-Cloud​

Establishing ZTNA within a chosen Cloud is relatively straightforward. Identity, policy, routing and visibility can be cohesively controlled from the Cloud Service Provider's (CSP) control plane. In the real world, though, ZTNA may be desired across Clouds or from Cloud to on-premise. The DiscrimiNAT Firewall is a ZTNA enabler for both of these use cases, and we shall dive deeper in Pillars of ZTNA section on the specifics of it.

But first, let's consider a hypothetical setup that involves a Desktop as a Service (DaaS¹) VM in the Cloud, its egress routing filtered by DiscrimiNAT and a legacy service running on an on-premise server. A user working from home logs on to the Cloud desktop and, amongst other tasks, also needs to connect to the legacy service running on-premise.

¹DaaS is called Amazon WorkSpaces on AWS
¹DaaS is called Virtual Desktops on GCP

DiscrimiNAT is based on packet inspection and is not a proxy technically. In this setup, the DaaS directly connects to the legacy/another Cloud service, with the network packets checked in-line by DiscrimiNAT. This enables low latency, great throughput and no interference with the protocol directly negotiated between the client and the server.

Developer Experience​

As we delve into the pillars of ZTNA below, we weave in how the DiscrimiNAT Firewall is a Cloud-native, developer-friendly enabler of ZTNA for DaaS.

Your data scientists should be able to self-serve the workstation side of ZTNA with our thoughtful design and tooling consideration. The pain of traditional perimeter constructs, such as subnets and classes of IP addresses, is alleviated for the developers.

We are confident in the developer-experience of our firewall solution.

Pillars of ZTNA​

In the following subsections, we explore how DiscrimiNAT Firewall approaches and addresses the tenets of ZTNA.

Least Privilege ⬇️​

The DiscrimiNAT allows setting of egress policies at a per firewall rule level. In AWS, this is done by adding annotations to Security Group Rules, and in GCP to the built-in Firewall Rules. Since firewall rules are associated to a specific VM or a group of VMs, this translates to granular policies segmented by logical grouping, as opposed to one policy for all. In the spirit of least privilege, this pattern can be applied to any group of VMs, and their access rights kept to precisely what's needed. It is recommended the service accounts (or instance profiles) in this design be representative of the entity accessing the DaaS, so attribution and identity mapping are not flawed.

Encryption in Motion 🔐​

The DiscrimiNAT only allows the use of contemporary encryption schemes at the network transport level. These are TLS 1.2+ and SSH 2 at the moment. Other schemes, such as plaintext HTTP are simply not allowed – not even with special configuration. This guarantees that data is always encrypted, with reasonable standards, in motion. Incidentally, this is also a requirement under NIST SP 800-53 SC-8 (Transmission Confidentiality And Integrity).

Application Discovery 🔍​

With DiscrimiNAT's monitoring mode, a precise list of remote applications that need to be accessed can be discovered with ease. The mode is activated with a special annotation to Security Groups in AWS², or to Firewall Rules in GCP². This annotation sets the firewall to non-blocking, monitoring mode, only for the groups of VMs associated with that firewall rule, until the date specified in the annotation.

What follows is extensive but JSON-structured logging of all outbound calls made from these DaaS. Documented queries can then be used in CloudWatch for AWS³, or Logs Explorer in GCP³, to present a list of all unique remote applications accessed in seconds. The data is rich with contextual information about the VMs that accessed it, the date & time of access, and the source & destination protocol metadata such as IP addresses and ports. The extracted report also highlights the exact firewall rules that were exercised for access, therefore leading back to the group of VMs responsible for access.

² See-Thru mode on AWS
² See-Thru mode on GCP

³ Building an Allowlist from scratch on AWS
³ Building an Allowlist from scratch on GCP

Continuous Assessment ♾️​

In the highly variable and dynamic DaaS-enabled workflows on the Cloud, the DiscrimiNAT monitors for changes in named-business application mobility, local policy and VM grouping at a near real-time pace.

Just-in-time access of remote business applications can be granted to groups of DaaS VMs bound together by firewall rules. Discovery of previously unseen applications or allow-all access can also be turned on for a micro-segment of identities, with the monitoring mode, and only for as long as necessary by setting an expiry date at the policy level.

Dynamic Application Identity ⚡​

The DiscrimiNAT copes without false-positives with CDN-hosted and on-premise business applications just based on their service name. This is down to our proprietary Wormhole DNS technology, developed with over two years of research, that can handle load-balanced, round-robin, weighted, etc. DNS responses perfectly well. Applications may be migrating from one site to another, and as long as their service name resolves to a working site, the DiscrimiNAT will dynamically keep mappings up to date and DaaS clients reliably connecting.

Dynamic verification is applied with every new connection request as well, with caching only to the extent of improving user experience and reducing latency. This ensures top-notch security in the Cloud landscape that can change very rapidly.

Policies @ Agile Speed 🌀​

By leveraging the Cloud provider's native APIs for policy storage and management, the DiscrimiNAT accelerates the learning phase of adopters dramatically in comparison to SASE/ZT vendors with proprietary UIs and constructs.

Combined with the monitoring mode discussed above (see Application Discovery), the toggling of which is also through the Cloud-native control plane, policies can be built with minimal effort and fed, without reformatting of any sort, back into the control plane with tools and processes already in place – such as the use of Terraform for Infrastructure as Code (Iac). Policy changes roll out in a couple of minutes, and enforcement begins to reflect impact on traffic flows in another minute or two.

Since IaC can be and is self-serve in most organisations, this blends well with Agile story-writing and completion because of the independent, estimable implementation of a policy change – without dependencies on other teams or departments.

User Identity Mapping 🛂​

With its first-class integration with the underlying Cloud platform, a DiscrimiNAT policy enforcement point (PEP) is able to map access policies in real time to the DaaS VMs. User authn is delegated to the Cloud-native Identity Provider (IdP), and authz to the user-role specific set of application groups. By continuously assessing this dynamic relationship and DiscrimiNAT's enrichment of logs with metadata, the gap between a software defined perimeter (SDP) and a user's identity is closed.

Being an agent-less solution, adaptive controls are only limited by the rate of change at the control plane – which with the Cloud scales infinitely – and implicit trust of a user being present on a network is removed by validating them just-in-time from the control plane interfaces, every time.

Protected Application Visibility 🛡️​

Remote business applications in a multi-cloud or on-premise environment can be shielded away from the general Internet with the use of source IP address allowlists. The DiscrimiNAT is able to dynamically bind⁴ to pre-allocated and earmarked egress IP addresses to maintain a stable, predictable outbound identity even as versions update and clusters re-balance.

With the use of IaC, these IP addresses can be dynamically updated across all parts of a multi-cloud infrastructure, virtually creating a Dark Cloud, and the shielded business applications will be removed from general public visibility for good.

⁴ Elastic IPs on AWS
⁴ External IPs on GCP

Default Deny ⛔​

Once deployed, all network traffic is denied by default. The DiscrimiNAT follows NCSC's Secure by Default principles and extends those to its interpretation of the control-plane configuration.

Group-wide policies to leave the solution in an "open" mode, however, can be applied in a time-controlled manner. This is the same mode that is used for FQDN Discovery (see Application Discovery discussed above) but can be left running perpetually should the requirements demand so. It remains restricted to a micro-segment of DaaS VMs, grouped with a native construct of the Cloud provider.

The default behaviour after the expiration of the set date in such a policy is to deny all traffic that is otherwise not allowed (from a different, associated policy.)

Next Steps 🚀​

Now that you've discovered the simplest DaaS ZTNA northbound firewall around,