The core principles of ZTBD attempt to harmonize guidance from disparate resources by distilling them down to foundational principles that capture the essence of zero trust.
|
1.
Trust no one (and no thing) Assume compromise. No user, device, packet, or input is implicitly trusted.
2.
What perimeter?
Secure perimeters have morphed or disappeared in a cloud-centric world with remote work and insider
threats. There are no implicit trust zones.
3.
Apply the principle of least privilege
Limit access to the minimum
required; deny by default where feasible.
4.
Dynamic, risk-based policies
Use dynamic, contextual risk assessment and strict policy
enforcement.
5.
Require strong authentication and
authorization
All resource access requests
and network flows should be authenticated and authorized.
6.
Log, monitor, inspect, and adapt
Traffic monitoring, input validation,
status logging, analysis, alerts, adaptive trust levels, issue prevention
and recovery actions.
7.
Employ defense in depth
Secure devices and
communications; secure the weak links; think like an adversary and
increase work factor for lateral movement.
8.
Full lifecycle, zero trust security
Full lifecycle security under a
zero trust model; security is not an afterthought.
9.
Confidentiality and integrity by default
Encrypt all communications;
protect data at rest; verify integrity.
10.
Strike the right balance with tradeoffs
Cost vs. benefit; security vs.
usability; cost proportional to risk/impact. |
In the ZT security model, no implicit trust exists and the network is assumed to have been compromised. The core principles of ZTBD embody the essence of the ZT model where all users, devices, network flows, inputs/outputs, and more should be considered hostile until proven otherwise.
While such a security model may have once been viewed as extreme, that is no longer the case in the face of APTs, myriad software vulnerabilities, supply chain attacks, insider threats, and more.
ZT Architectures lack implicit trust that might be found in legacy networks with perimeter centric security models. ZT Networks can be thought of as having Internet security everywhere.
If one assumes the network has already been compromised, the goal then becomes preventing lateral movement and increasing work factor. ZT architectures typically employ dynamic, risk-based policies to ensure that all users, devices, and network flows are strongly authenticated and authorized.
For more information, links to resources such as the NIST Zero Trust Architecture standard SP 800-207, the Zero Trust Architecture entry in the Encyclopedia of Cryptography, Security and Privacy, and the DISA zero trust reference architecture may be found in the Resources Section.
When viewing software engineering through the lens of the zero trust (ZT) security model, we explicitly recognize the evolving threat landscape and the need for modern software solutions to integrate with ZT network architectures. In an increasingly API driven world of cloud-based infrastructures and remote workforces, ZT software engineering tailors full lifecycle software engineering practices to enable improved realization of the zero trust environments in which the software will execute.
For more information, links to resources such as API security enablers, static code analysis tools to incorporate in continuous integration pipelines and more, refer to the Resources Section.
Zero trust protocols are the foundation for both ZT software engineering and ZT protocol design. Even the most secure software or the most hardened ZT network will fail to facilitate a strong security posture if they leverage insecure protocols developed without a ZT mindset. ZT protocols can be sub-divided into at least two broad categories including ZT networking protocols and domain specific ZT protocols.
Zero Trust Networking Protocols: Protocols for ZT networking can strengthen existing ZT networks and enable new capabilities. Further development and enhancement of open standards in this area could further facilitate adoption and maturation of ZT networks. Examples of such ZT networking and related protocols include protocols for log parsing/orchestration/threat response to enable "autonomic security" for ZT networks, a generic firewall policy language to foster dynamic enforcement of access control policies, and use of first packet authentication and transport access control for zero trust cloud network implementations.
Domain Specific Zero Trust Protocols: The design of novel protocols for specific domains can also be approached with a zero trust mindset. There are a number of examples of protocols that embody one or more elements of ZTBD. For example, such domain specific ZT protocols span areas from electronic crypto-currencies to novel privacy-enhanced matchmaking protocols and zero trust management in hierarchical IoT networks. For more details, see the Resources Section.
The set of good practices for zero trust contexts accompanying the growing ZTBD body of knowledge connect theoretical guidelines with practical applications. Go to Contribute/Contact to learn how you can suggest additional good practices for ZTBD enablers.
There is no longer a safe internal network inside a secured perimeter (maybe there never was!). Perimeters are dissolving with cloud-based infrastructure, remote workforces, BYOD, APTs, insider threats, and more. Even the best perimeter defenses can be circumvented.
Assume connection requests and packets are hostile until proven otherwise. For instance, consider using mutually authenticated Transport Layer Security (TLS) (and plan to migrate to post-quantum TLS when feasible).
The SolarWinds attack of 2019-2020 significantly impacted government agencies and Fortune 500 companies. It was a reminder of just how critical it is to secure the software supply chain. Be sure to consider the entire supply chain including code/artifact repositories, build systems, dependencies, DevOps continuous integration pipelines, and more.
Access proxies can add a level of indirection and provide useful functions like enforcement of access controls, denial-of-service protection, traffic anomaly detection, and more. A good example of this can be seen with Google's BeyondCorp implementation.
More Zero Trust Protocol Design and Software Engineering Practices are coming soon.
Strong identity validation is essential for trust evaluation and access control. Leverage multiple factors for authentication such as something the user knows (e.g., password), is (e.g., biometrics), and possesses (e.g., token).
Managed devices should be securely configured with trusted images, secure provisioning, and strong identification (for example, this may include use of a Trusted Platform Module (TPM) and standards X.509 certificate schemes).
Devices should always be in the most secure state possible. Ensure timely patching of OS, applications, and firmware. Consider patch level, general security posture, and potentially time since last trusted image load as factors in trust evaluation. Leverage appropriate security tools like firewalls, intrusion prevention software, antivirus, and potentially user activity monitoring. Consider tailored access controls and custom policies for different device types. For example, a company provisioned laptop might be treated differently than BYOD or IoT devices.
Similar to the early work of Sood et al. on zero trust intrusion containment, consider a strategy to periodically restore from trusted base images. Consider age of device image to be a risk factor (e.g., more time since original imaging implies increased likelihood of compromise).
More Zero Trust Networking Practices are coming soon.
Zero trust design patterns foster ZT success with reusable solutions to commonly recurring challenges. Zero trust patterns can apply to ZT network architecture, ZT protocol design, and/or ZT software engineering. Go to Contribute/Contact to learn how you can suggest additional patterns for the ZTBD body of knowledge.
Problem: I need to ensure confidentiality of information exchanged.
Solution: For end-to-end confidentiality guarantees use application layer encryption with strong ciphers.
Details: Software should not rely on confidentiality mechanisms at lower layers. Link-level point-to-point encryption and VPNs can offer benefits, but they can leave traffic vulnerable outside of the encryption context. Use encryption at the application layer for confidentiality between endpoints.
More zero trust software engineering patterns are coming soon.
Problem: My protocol uses key exchange mechanisms like RSA and ECDH that are vulnerable to quantum computing enabled attackers using Shor's algorithm.
Solution: Leverage post-quantum cryptography. However, note that full confidence cannot be placed in candidate quantum-resistant cryptographic algorithms prior to NIST standardization and quite possibly for some time thereafter. In the interim, combine classical and quantum-resistant algorithms in a hybrid scheme that combines the approaches to accomplish the soundness of the strongest approach in the event that the other is weakened or compromised.
Details: NIST in the USA has invited global cooperation for evaluation and standardization of quantum-resistant cryptographic algorithms. Draft standards are planned for the 2024 timeframe. In the meantime, hybrid post-quantum protocols are being designed for research, testing, and preparation for security against quantum enabled adversaries. The post-quantum hybrid Transport Layer Security (TLS), a hybrid post-quantum protocol for fair and privacy-enhanced matchmaking, and X.509 compliant hybrid certificates are three examples of applying this pattern.
Problem: How can I limit a service to authorized packet flows only as part of my zero trust architecture?
Solution: Use SPA where the payload of the first packet includes information to authenticate the originator and authorize the data flow. In this scheme, packets are passively monitored and dropped by default if not properly pre-authenticated as an authorized flow.
Details: Refer to the Software Defined Perimeter (SDP) 2.0 specification from the Cloud Security Alliance (CSA) for details about an example implementation of this pattern.
More zero trust protocol design patterns are coming soon.
Problem: I need to choose the right PKI for certificate based authentication schemes in my ZT network architecture.
Solution: Prefer a private PKI system over public PKI entities.
Details: Public PKIs are a good fit for many situations. But the implementation of ZT networks tends to result in a significant increase in the number of certificates required and frequency of certificate generation/updates. Private PKIs can have fewer risks and more benefits in a ZT environment. For instance, private PKIs can offer cost advantages as well as increased control over the certificate creation and rotation processes. Private PKIs can also offer more flexible automation opportunities. Another consideration is that the extent of trust in 3rd parties could come into question with the very large number of public PKIs and associated trust chains. Refer to the book from Gilman and Barth in the ZT Resources section for more on the discussion of public vs. private PKI in ZT networks.
More zero trust networking patterns are coming soon.
Practitioners may find the following Zero Trust Resources to be useful. Although they are organized into groups, there is some overlap across categories. Feel free to reach out to us if you have additional resource recommendations for the growing Zero Trust by Design Body of Knowledge (ZTBD-BOK).
Are you unsure where to begin the zero trust journey for your research group or your employer? Consider creating a zero trust testbed. By combining the power of software defined perimeter (SDP), software defined networking (SDN), virtualization, and open source software you can create a zero trust testbed with limited resources. Even a student equipped with only a laptop can get started with zero trust experimentation today!
D. Horne (2022) "Leveraging Software Defined Perimeter (SDP), Software Defined Networking (SDN), and Virtualization to Build a Zero Trust Testbed with Limited Resources", In Advances in Security, Networks, and Internet of Things (SAM, ICWN, ICOMP, ESCS 2022), Springer, Cham.
With the use of single packet authorization (SPA) to facilitate service hiding via an authenticate and authorize prior to access model, SDP aligns well with the ZTA as defined by NIST. The following figure from the paper shows how components of SDP map to core concepts of ZTA.
The following Mininet network diagram gives an example network configuration that one might create for zero trust testing.
| Software | Purpose | License Type |
|---|---|---|
| Ubuntu | Host OS - a Debian-based Linux | Various |
| SDP Host/Gateway | SDP components based on fwknop | GPLv2 |
| SDP Controller | SDP Controller from Waverly Labs | GPLv3 |
| Mininet | SDN based virtual network simulation | Mininet 2.3.1b1 License |
| Hidden Services | Protected services under test | Various |
| Software | Purpose | License Type |
|---|---|---|
| Pritunl Zero | BeyondCorp server, controlled privileged access (to web apps, SSH, etc.) | Pritunl License |
| OpenZiti | Zero trust networking for apps | Apache 2.0 |
| Prometheus | Zero trust monitoring of system/service (uses OpenZiti) | Apache 2.0 |
| privacyIDEA | Multi-factor Authentication (MFA) (OTP tokens, SMS, email, SSH, etc.) | Affero GPLv3 (copyleft) |
| OpenIAM | Identity & access management (IAM) | Various |
| OpenAM CE | Identity & access management (IAM) | CDDL 1.1 |
| Gluu | IAM & MFA for web & mobile apps | Various |
| Drools | Inference-based rules engine | Apache 2.0 |
| Mender | OTA updates, device config for embedded/IoT | Apache 2.0 |
| Trivy | Vulnerability scanner | Apache 2.0 |
We invite the community from both academia and industry to provide feedback on the ZTBD Principles, or to contribute additional good zero trust practices and zero trust patterns as we evolve toward ZTBD v2.0. Join our zero trust alliance as we work together to foster the next generation of zero trust technologies.
Cite ZTBD v1.0 content as: D. Horne and S. Nair (2021) "Introducing Zero Trust by Design: Principles and Practice Beyond the Zero Trust Hype". In: Advances in Security, Networks, and Internet of Things (SAM, ICWN, ICOMP, ESCS 2021), pp. 512-525, Springer, Cham.
Cite ZT Testbed content as: D. Horne (2022) "Leveraging Software Defined Perimeter (SDP), Software Defined Networking (SDN), and Virtualization to Build a Zero Trust Testbed with Limited Resources". In Advances in Security, Networks, and Internet of Things (SAM, ICWN, ICOMP, ESCS 2022), Springer, Cham.
