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

ama
security

(Alex Maier) #1

On August 17th, 11-noon Pacific time, we’ll be hosting an AMA session with Evan Gilman and Doug Barth, authors of Zero-Trust Networks.

Perimeter defenses guarding your network aren’t as secure as you might think. Hosts behind the firewall have no defenses of their own, so when a host in the “trusted” zone is breached, access to your data center is not far behind. This practical book introduces you to the zero trust model, a method that treats all hosts as if they’re internet-facing, and considers the entire network to be compromised and hostile.

Evan Gilman is an engineer with a background in computer networks. With roots in academia, and currently working in the public internet, he has been building and operating systems in hostile environments his entire professional career. An open source contributor, speaker, and author, Evan is passionate about designing systems that strike a balance with the networks they run on.

Doug Barth is a software engineer who loves to learn and shares his knowledge with others. He has worked on systems of various sizes at companies like Orbitz and PagerDuty. He has built and spoken about monitoring systems, mesh networks, and failure injection practices.

Evan and Doug will be online answering your questions from 11am to noon Pacific time on Thursday, August 17.

Ask your questions in the thread below (either beforehand or during), and don’t forget to use the “watch” feature on the thread to be notified.


(Max Timchenko) #2

Evan and Doug, my question is about some recent services like WireGuard (https://www.wireguard.com/). They claim a solution based on a new, much simplified protocol instead of the IPSec stack.

What is your opinion on this approach? Do you think the authors of WireGuard are correct to dispense with the legacy stacks altogether, or are they likely to run into issues or problems already solved by these older protocols, as well as into potential security problems due to less focus from the security community on their algorithms?


(David Hayes) #3

Doug, I’ve often been in awe of how you keep your facial hair under control, any tips that Mr Gilman could benefit from?


(Jonathan Curry) #4

Can I really trust localhost? :thinking: It always looks at me funny…


(Alex Maier) #5

What technology blogs/podcasts do you follow and would recommend to our community?


(Rich Adams) #6

Hi Evan and Doug! o/

I think one of the problems a lot of companies have is that they’re very set in their ways when it comes to security, and changing their current model can be a large challenge that’s met with resistance. Do you have any advice for how organizations can start to embrace the zero-trust model without necessarily needing to re-design their entire infrastructure? What’s the first step they can take to move towards a zero-trust design?

As a follow-up question, if someone were building a brand new system from scratch and wanted to use a zero-trust approach, what are some of the gotcha’s they should watch out for when designing their system? Any things that they can do early on to save themselves pain later?


(Kevin Babcock) #7

What most surprised you during the writing and publishing of your book? What was the hardest part?


(Eric Sigler) #8

Howdy!

At first glance, zero trust networks seem like they could add additional complexity and operational overhead to running infrastructure. How would you go about minimizing this additional effort?


(Eric Sigler) #9

Also, are zero trust networks appropriate for all forms of infrastructure? Where should and shouldn’t they be used? Are there any particular applications / use-cases that should be included or avoided?


(David Kua) #10

Raccoon or Strongswan?


(Ryan Hoskin) #11

What are your thoughts on politicians calling for bans on encryption?


(Doug Barth) #12

I’ve found being in a relationship with someone who refuses to kiss you if you haven’t shaven works wonders.


(Doug Barth) #13

With the increased usage of sidecars, security folks are wary of services listening on localhost because those ports are accessible to malicious software running on the same device. This is especially true for laptop devices which are on the front lines of attacks. Using domain sockets is preferred, assuming a system administrator can manage the permissions to ensure that only the intended clients are able to access the socket. A fair amount of Linux services use this pattern, and I think it’s a good one to keep in mind as companies build new systems.


(Doug Barth) #14

Strongswan. I might’ve once said that ipsec-tools (the project that provides the Raccoon IKE daemon) is “hosted on Sourceforge using CVS as their version control system, which is the definition of abandonware”.


(Evan Gilman) #15

This is a great question.

I really like WireGuard. It has some great properties, and its operation is vastly more simple than IPsec or TLS. Performance is also there. It is based on Noise, which is the new hotness

Due to the fact that it’s based on the Noise framework, it presents less risk from a crypto vulnerability point of view, since they are basing the “hard” stuff on a shared and fairly well-understood framework. Whatsapp uses Noise too. So, I don’t think we’ll see too many problems on that front…

I do think, however, that some of the newer crypto trades old problems for old problems. X.509 is usually left out due to its complexity, however no suitable replacement is made available. As a result, WireGuard currently suffers from a key distribution problem, since the question still exists of “how do I get the right public keys”. X.509 solves this by chaining trust and signing… some similar approach will need to be taken with WireGuard, but is not defined.

So, TL;DR, I think the work is very promising, but the operators must solve for some problems before they’ll be fully suitable for large scale production environments.


(Evan Gilman) #16

Depends :slight_smile:


(Doug Barth) #17

There’s a lot that surprised me personally. First off, I felt a TON of imposter syndrome. I think this is doubly so because we’re talking about security, which requires rigorous thinking about every detail of a system. Having a partner to help write the content and lots of discussions with people with even more experience in security helped me feel confidant that we were on the right track.

I was also pleasantly surprised with how willing people were to help us with the book. We made so many new connections, often from straight up cold emailing, which were incredibly valuable. My advice for someone who wants to reach out, people are willing to help as long as you’re professional and have done your homework.

There are little tidbits about the writing process that I found interesting. Our writing speed picked up during the course of the book (a function of us having a clearer framework for presenting the content and practice). We found near the end that pairing on writing content in a Google Doc worked really well. We would tradeoff sections where one person is leading and the other is following behind suggesting edits. Much like pair programming, the end result was more easily produced because you could bounce an idea off someone, and we had already done the obvious editing during the process.

In retrospect, writing a book like this seems harder than writing a book on a new technology (perhaps that’s just a grass is greener fallacy?). If you like to write and learn about new technology, playing with the tech and writing content so others can more easily learn what you now know seems like a great opportunity.


(Evan Gilman) #18

You’re absolutely right, cultural shift is super important for zero trust adoption, and of course is very difficult to do. If you can get people to think about it the right way, however, the infrastructure may naturally evolve towards a more zero trust centric stance. For instance, if folks can understand why it is important to authenticate requests, and tools to make this easy can be made available, you’ll eventually find yourself in a place where authentication occurs more often than not. This is a great start. You don’t have to bite the whole thing off at once.

In terms of what can be done early on to save pain later, I think the answer there is to maintain a dependency graph. Who talks to what and how. This graph will be invaluable in enforcing policy. Ideally, you will try to enforce this graph sooner rather than later, as enforcement means it will be kept up-to-date, necessarily. So, building and maintaining that graph is a great thing to get started on early.


(Evan Gilman) #19

Never racoon… never racoon :slight_smile:

As Doug always says, SourceForge is a place software goes to die
http://ipsec-tools.sourceforge.net/


(Evan Gilman) #20

Holy moly, it’s a lot of work! That was most surprising, surprisingly :slight_smile:

I mean, you know that it’s “a lot” of work going into it, but the undertaking was so huge that it was hard to understand the scale. Exactly how much “a lot” is was the biggest surprise.

The hardest part was getting up at 6am every day to write before going to work.