AMA with authors of Zero-Trust Networks: August 17, 2017


(Doug Barth) #21

A meaty question! This question touches on the security vs. privacy tradeoff. As the world moves towards increasing use of end-to-end encryption, a passive observer on the network isn’t able to simply collect traffic to do analysis. Interestingly, companies are also dealing with this problem because so much network security has traditionally been about sniffing traffic on the wire. It’s not just governments or companies that are able make use of unencrypted traffic, however. Well placed malicious actors can also take advantage!

For myself, I don’t see how we continue to have a globally connected network without encryption. Calls for “golden key” solutions which weaken the security for an assumed good actor also create an opportunity for a bad actor to exploit it (key management is hard!).

(Evan Gilman) #22

We like to say that automation is the reason that the zero trust architecture is feasible. There are a lot of ways to go about building this automation, and different approaches make sense for different people.

The “service mesh” pattern makes a lot of sense in many ways. Projects like Istio and linkerd put forth opinionated patterns which provide security under-the-covers, absolving the developer from needing to think about such complexities. In general, I think this is the right approach. Not to say that you need a service mesh, but to say “How can I deliver this functionality in a way that happens automatically, and how can I ensure that developers don’t have to do silly things like configure TLS”

(Evan Gilman) #23

This is an interesting question… The zero trust model is best applied towards organizations/companies/autonomous systems. Namely, systems which are fully controlled by a single entity. This architecture tends to break down once communication patterns involve systems owned by different entities - we don’t have a good solution for federation. We also don’t have a good solution for public trust. Hopefully these are things we can figure out in the coming years.

(Doug Barth) #24

I think zero trust networks should be the default for most networks, especially in corporate or organizational settings. Home networks will be difficult to roll out zero trust practices in since so many devices are vendor devices, which means you have less control. For devices that have RJ45 interfaces, it would be interesting to imagine a world where one could put a zero trust control device right into that interface and then have the network cable connect to that control device. Perhaps there’s an opportunity for the industry to shrink that pattern down into an IC which sits on the motherboard is handles that responsibility.

An interesting use case where encrypted zero trust networks might not be desired is when its advantageous to allow passive observers to see the traffic on the network. One example, perhaps voting systems should transmit votes in a way where the contents are known, but the traffic can’t be modified. In a way, the network is still using zero trust principles (the traffic is transmitted in a way that the content can’t be compromised), but these networks are purposefully dropping the confidentiality guarantees that most networks would want. You just better be sure that the data you’re transmitting should in fact be public!

(Evan Gilman) #25

Oh man… well the knee-jerk reaction is “heck no!”

Writing the book has forced us to think a lot about the philosophy of the security/privacy tradeoff. It is very much a tradeoff, and I don’t think it’s possible to achieve both simultaneously.

One of the interesting things we came across was while researching the use of TPMs (a hardware chip which provides strong platform identity and security). We found that a lot of work had been done in recent versions of the remote attestation protocol in order to provide privacy. This was due to the fact that folks had begun to use TPMs to enforce DRM, and that the integrity of the TPM would be checked prior to allowing the music (or whatever) to play. This was a major privacy concern, because it meant that folks controlling the DRM would get to know the “real” identity of the hardware wanting to play it. To solve for this, the protocol was changed such that the posture could be checked without revealing this identity. Lo and behold, this is exactly the opposite of what we wanted!

So, I strongly believe that encryption is necessary, and should be applied in a ubiquitous way, with endpoints controlling the keys. I acknowledge the fact that it is very difficult to give traditional security guarantees in this brave new world, however perhaps the answer is that we need evolve our security posture to take this into account. For instance, it was erroneously publicized that Whatsapp encryption was “hacked” because a law enforcement agency was able to uncover messages sent by it. Turns out that they didn’t actually break the encryption - they just hacked the phone and took a screenshot of the messages. Law enforcement tactics like this are still effective in the face of end-to-end encryption. And good news for us - these tactics must happen in a targeted way, as opposed to the dragnet approach that is commonly employed today.

Also, IMO one motivator to break or ban encryption is that wide adoption of secure end-to-end encryption is sinking very large investments made by certain governments

(Doug Barth) #26

I agree with what Evan said. There’s an interesting talk that looked at what it takes to defend yourself from a state actor (eg. Russia, China, etc.). A statement that stood out to me in that talk was an attacker’s job is to know your network better than you know your network.

Just to be clear, most networks are not being attacked by state actors, so the goal isn’t to declare your network immune to state-level threats. But you can still broaden your understanding by seeing what an adversary with effectively unlimited resources would do.

(Evan Gilman) #27

Hmm that’s a hard question. I’ve found that I’m reading less blogs and listening to less podcasts… but I am engaging more in various community slack channels and conferences. Perhaps the most valuable advice I can give on this front is, get out and go to conferences and/or meetups etc. Engage with the community and the industry. It may surprise you how much is going on out there that you’re not aware of. Ask people about what problems they’re solving, and ask them what they think about the ones you’re solving. Blogs etc don’t always do a good job of picking those bits out.