Published June 2022. Product names and platform availability reflect adam:ONE® at that time; see the Technical Brief for the current technology stack.
Background
The missing tenet
Zero Trust (ZT) is a set of philosophical tenets born out of past security failures. The core tenets carry huge value, but there are substantial gaps between the raw philosophy and the practical implementation available to most security administration teams today.
A great idea that cannot be executed is mostly useless. One of the tenets we see as a requirement for effective security is the ability to execute the philosophy.
Zero trust presents a shift from a location-centric model to a more data-centric approach for fine-grained security controls between users, systems, data and assets that change over time; for these reasons, moving to a ZTA is non-trivial.
— CISA Zero Trust Maturity Model, Pre-decisional Draft v1.0, June 2021
The marketing fog
Zero Trust has also become an industry buzzword that marketers attach to products to appear more relevant. Using the term does not make a security solution answer the needs Zero Trust exists to address.
For the sake of distinction, we use the term Zero Trust Connectivity (ZTc) for the specific aspects of the Zero Trust philosophy executed through controlled network connectivity: not only between verified assets but, more importantly, between verified assets and every other possible outgoing connection, including the public internet.
Design from first principles
Zero Trust is a reaction to the security failures of previous philosophies, but it is about much more than user identity and access.
In our experience, practical solutions to those failures start by identifying the design flaws that caused them, then designing from first principles to address them. For interconnected devices, it helps to break the evolution of the internet and its technologies into three phases:
- Build application functionality: “Get stuff to work.”
- Optimize application delivery, usability and utility: “Get stuff optimized.”
- Secure the application and protect the user and data: “Get stuff secured.”
The building blocks of the internet, and how assets connect, have matured well for phases 1 and 2. The lack in phase 3, security, is evident in the current cyber threat landscape.
When humans are involved, the three phases form a paradox. Security has an experience and convenience cost, and convenience has a security cost. Effective, practical security exists within the balance of all three.
At its core, a Zero Trust approach inverts the original design intent of the internet, which was to route around any obstruction. That legacy approach left us with the philosophy:
“Trust by default, deny threats.”
Because threat actors exploit that default, we have no choice but to invert it:
“Deny by default, trust verified connections.”
That inversion has been the foundation of adam:ONE development, piloted by designing from first principles. The rising Zero Trust philosophies align with the design tenets we developed for adam:ONE, which is why we use the terminology.
Main goals for the adam:ONE design that intersect with Zero Trust philosophies
- Implementation must be practical.
- Remain operational while assuming breach.
- Leakproof egress control.
- Apply protection proactively, without needing a detection trigger.
- Deny all connections and access unless verified to be necessary and good.
- Achieve real-time visibility to each connection.
- Achieve maximum visibility to each asset.
- Automated real-time device inventory.
- Protection for all asset types: access devices, IoT and OT including legacy assets, regardless of OS.
- Aggregate threat intelligence.
- Multiple layers of protection: defense in depth.
- Distributed custodial protection.
- Granular control to enforce policies of access and execution, remaining dynamic when appropriate.
- Flexible perimeters that remain dynamic.
- Circumvention protection.
- Encryption friendly: never break end-to-end encryption during protection.
- Privacy friendly.
Predecessor technologies
Internet security moved from firewalls to transparent packet inspection, then to next-generation Unified Threat Management (UTM) supplemented by threat intelligence from constant threat hunting. The rapid adoption of encryption in transit upended all of it.
DNS firewalling was one control plane that partly remained. Provided network devices behaved as they should, it stopped DNS queries for known threat actors from resolving. The result was an accelerated cat-and-mouse game between threat intelligence feeds and malicious actors registering new domain names, including widespread domain generation algorithm (DGA) domains. Advanced DNS firewalls then added IP address reputation systems.
Next, vendors centralized traffic redirection to use cloud capacity for inspection. They make varying use of proxies, issuing their own CAs and TLS certificates to endpoints to keep visibility and manageability of all traffic:
Well-intentioned service providers rely on decrypting SSL/TLS traffic through proxies or self-signed certificate trust.
Honouring TLS and end-to-end encryption without proxies
Endpoint users and applications rely on a trustworthy connection to a service provider. Network administrators have traditionally been at odds with that, because they are responsible for keeping endpoints safe from threats.
To maintain end-user privacy and honour end-to-end encryption, security must be split into two separate control systems:
- Secure Access Service Edge (SASE): allows or disallows every OSI layer 3+ connection.
- Endpoint security: inspects and protects against malicious intent after decryption and before encryption.
Distributed custodial protection, shown at the top of this page, keeps traffic under each site’s own control, with a custodial aggregation point only for multi-homed devices. Only this approach honours the privacy and security expected of end-to-end encryption.
Distributed custodial network protection
Muscle-brain
An on-premises, gateway-hosted client (the “muscle”) continuously receives its configuration from a centralized cloud controller (the “brain”). That optimizes resilience and local performance at the same time. DNS queries and answers stay in geographic proximity to the endpoint, and every network traffic decision is made locally.
AI-powered dynamic allow-listing
A default-deny policy that commits to “deny all, trust verified connections” needs flexibility, so each policy can match the right security posture while staying convenient and practical. Different allow-listing approaches right-size a policy to the role of a user or device:
| Allow-list policy type | How it works | Typical use case |
|---|---|---|
| Fixed rule(s) policy | Pre-made lists or observation establish the required internet domains and FQDNs as an allow-list. | Active Directory controllers, file and application servers, web servers, IoT devices, printers and scanners |
| Adaptive allow-listing policy | A per-site or per-network policy adds a domain each time it is requested by the user, passes cloud-based sandbox testing and AI inspection, and is in a safe-for-work category. | End-user devices where the user’s role is well defined (such as accounting), phishing protection is essential, circumvention protection is paramount, or the asset is high value |
| Reflex allow-listing policy | A per-device policy sorts 80 categories into five decision buckets: Always Block, Block, Review, Allow and Always Allow. Conflict resolution can be Permissive, Protective or Hold for Human. | Users who need a relatively permissive policy with strong protection and do not fit the categories above |
Don’t Talk To Strangers (DTTS)®
A stranger, in this context, is an IP address that has not been resolved through a permitted DNS query. Disallowing such communications follows this logic:
Every modern advanced persistent threat relies, at some point in the attack chain, on a direct-by-IP connection to a command-and-control (C2) operator waiting for phone-home connections. These are notoriously difficult to detect, even for security operations centers, and are too often identified only when it is too late. DTTS® stops the threat before it does damage.
This approach produces many thousands of firewall rule changes per minute at each layer 3 connection on a typical network, yet it scales because they are all made in user space.
DTTS® makes DNS firewalling leakproof.
Exceptions are administered through Enablers. An Enabler defines destination IPv4 or IPv6 address space with protocol and port numbers. Enablers are typically needed for latency-sensitive services such as voice and video, which are easy to identify and enable with the supplied administrative tools.
DNSharmony®
Domain reputation systems and threat intelligence sources are readily available, commercially and as free or open source. There is no need to rely on a single source; that is the concept behind DNSharmony®. Consider an end-user device that wants to resolve fqdn.example.com. The most acceptably permissive policy could aggregate:
- Cloudflare 1.1.1.3 / 1.0.0.3 (blocks known malware and adult content)
- CleanBrowsing Security Filter (185.228.168.9 / 185.228.169.9)
- Quad9 (9.9.9.9 / 149.112.112.112), which itself contains commercial sources
- Enterprise-sourced threat intelligence through BIND RPZ subscriptions
- Pi-hole running on a local network edge
A DNSharmony® policy blocks fqdn.example.com if any of those providers answers with its block response (NXDOMAIN, a block page IP and so on). Aggregating every available source gives superior protection against known threats.
Additional network security principles applied to ZTc
Protecting devices and channels of every kind with data integrity requires further principles:
- Do not rely on proxies anywhere, whether local or operated by a third party in the cloud.
- Do not break encryption, for example with SSL decryption appliances.
- Offer flexible perimeters for multi-homed and mobile devices.
Network segmentation
Segmentation is a reasonably light administrative load when executed properly, and when even internal resources are reached by FQDN rather than IP. Rather than giving a business unit access to 10.12.13.14 for an internal application, offer https://app1.internal.example.com, which also lets the resource move without future pointer changes.
Typical network segments separate role-based functions per site, for example:
- Active Directory controllers
- Network management (switches, controllers and so on)
- File servers
- Printers and scanners
- IoT Ethernet (including security cameras and door control systems)
- Staff Wi-Fi (802.1X)
- IoT Wi-Fi
- Guest Wi-Fi
Microsegmentation is also effective, especially for multi-homed devices. Distributed custodial protection includes microsegmentation by default, and adam:GO™ can be distributed through an MDM-pushed always-on VPN to the aggregation sites.
The default firewall rules between segments permit no traffic. Traffic is allowed only as the device or user policy defines.
Modern Zero Trust philosophies sometimes discount network segmentation, which leaves a significant source of threat vectors open. Network devices that are not end-user devices have no other protection available. Printers, scanners, cameras and control systems are almost universally vulnerable; fixes are slow to arrive at the source and slower to be deployed. ZTc provides important protection against lateral movement from such devices.
Layer 2 visibility
Every device in a network must have layer 2 visibility to the SASE.
Inventory enforcement via a quarantine default policy
Whenever the SASE discovers a new device, it automatically assigns a policy that passes typical connectivity checks and nothing else. That limited state makes the device reveal its next-stage functionality, which makes it practical to investigate passively and apply the right policy.
Per-user policy assignment with 802.1X
Most modern mobile devices use random MAC addresses. 802.1X provides an immediate device-to-user mapping for policy assignment.
User-friendly TLS/SSL blocking without breaking trust
Showing a friendly page when a secure site is blocked is a solved problem. It is not solved by trusting a self-signed certificate, but by a browser extension that reads the TCP reset and redirects to a friendly block page at mytools.management. The result is transparent to the user and does not break SSL/TLS.
DoH and DoT: proper placement of secure DNS
Where the DNS channel needs protection, it must be protected internally. DoH-based C2 channels alone justify disallowing enterprise user devices from using publicly available DoH servers.
Disabling UDP reflection attack participation
DNS (UDP port 53 by default) and NTP (UDP port 123) are the two standard protocols most commonly used for UDP reflection and amplification attacks. This vector is mitigated completely by:
- Offering DNS and NTP services on every internal segment.
- Forcing internet-bound requests to be answered locally.
The result of Zero Trust Connectivity
- Strong mitigation against typical adversarial network attacks; for example, Active Directory is unreachable by an attacker trying to move laterally.
- Protection against the unknown threats of tomorrow.
- Attack surface reduced to near zero: effectively 7,000:1.
- C2 communication prevented before it can occur.
- Protection against data exfiltration.
- Human factors considered, with phishing protection.
- Spear phishing mitigated. IPv6 has enough unique addresses to attack every person 47 octillion times.
- Shadow IT cleanup: no unauthorized remote connections remain possible, including on BYOD endpoints.
- Circumvention protection.
- Privacy.
- Productivity.
- Distributed custodial protection.
- Decentralized performance with centralized control.
Platform availability in 2022
- pfSense® (available with optional HA and SLA)
- ClearOS® (via marketplace)
- Debian (available on the managed platform)
- Asuswrt-Merlin (for evaluation, proof of concept and SOHO use)
- Docker container
- VyOS® (coming soon at the time)
Binaries were available for multiple architectures, including x86, ARM and MIPS.
Glossary
| Term | Meaning |
|---|---|
| ZTc | Zero Trust Connectivity |
| SASE | Secure Access Service Edge |
| DoH | DNS over HTTPS |
| DoT | DNS over TLS |
| CA | Certificate Authority |
| FQDN | Fully Qualified Domain Name |
| DNS | Domain Name System |
| NTP | Network Time Protocol |
| E2E | End-to-end encryption |
| BYOD | Bring Your Own Device |
| IoT | Internet of Things |
| OT | Operational Technology |
| MITM | Man in the middle |
| HA | High Availability |
| SLA | Service Level Agreement |
