Notes from _Zero Trust Networks_, part 3
• Mark Eschbach
Trusting Devices (Ch 5)
This chapter tries to postulate solutions on authentication and authorizing devices into the trusted network. This is an incredibly hard problem no matter how you slice it. If you are unfamiliar with PKI and standard network practices this chapter offers little. I am a bit concerned about the authors understanding of TOTP or I severely misunderstand the technology; I’m going with concern here.
A proposed solution is to use TPMs to contain the private key and have a human authorize devices coming on-line. Although the book touches on the limitation to use features like auto-scale groups, mainly using such features is fundamentally incompatible with the result.
Trusting Users (Ch 6)
This chapter goes over the basics of user trust. Only relevant portion to the ZTN philosophy is various types of human authentication and trust chains should change the trust score.
Trusting Applications (Ch 7)
ZTN discusses the whole software supply pipeline as a threat vector. They recommend the standard position software should be signed when the artifacts are produced and verified when running. Further it is recommended the software is verifies it is running on an authorized host.
Trusting the Traffic (Ch 8)
This chapter goes in depth to many of the protocols able to secure traffic on the fly. ZTN recommends using TLS for client to server communication and IPsec for server to server communication. There is some mention of network routing and rules. If you forgot basic networking (OSI versus IP models) you might want to read this chapter.
Realizing a Zero Trust Network (Ch 9)
The requirements of a Zero Trust Network are layed out as followed:
- All network traffic is encrypted and authenticated
- A private PKI system should be used internally.
- Encryption should be done at the endpoints instead of inflight.
Obviously the devils in the details. A core principal is the control plane allowing authenticated clients to access specific services. The control plane is responsible for throwing the switches which allow for communication after authorization.