Bonus: Cybersecurity Canon Hall of Fame interview with Doug Barth and Evan Gilman.

Rick Howard: The CSO Perspectives podcast finished its fifth season last week. And we are working hard on season six that will begin on 19 July. But don't feel sad, we have a special treat for you instead. The Cybersecurity Canon Project announced the author selectees for the Hall of Fame Awards in 2021 back in May. And, you all know that I am a huge advocate for reading in general, but specifically we all need to read more good cybersecurity books. And I emphasize the good there because there are a lot of published, bad cybersecurity books out there.

Rick Howard: And I have been involved in the Cybersecurity Canon Project since the beginning in an attempt to find the books that all of us should have read by now. And the reason that I'm excited today, is that I get to interview the authors of one of the 2021 Hall of Fame Awardees Doug Barth and Evan Gilman, the authors of "Zero Trust Networks: Building Secure Systems in Untrusted Networks" that they published in 2017.

Rick Howard: My name is Rick Howard. You're listening to CSO Perspectives, my podcast about the ideas, strategies, and technologies that senior security executives wrestle with on a daily basis.

Rick Howard: The Cybersecurity Canon Committee selected five books for inclusion into the Hall of Fame this year: "Transformational Security Awareness" by Perry Carpenter, "Code Girls" by Liza Mundy, "Like War" by Peter Singer and Emerson Brooking, "Sandworm" by Andy Greenberg, and "Zero Trust Networks: Building Secure Systems in Untrusted Networks" by Doug Barth and Evan Gilman. 

Rick Howard: I asked Evan why they wanted to write this book on zero trust.

Evan Gilman: I guess I'll start since I'm the troublemaker that incited all this crazy stuff. Doug and I did a bunch of work together many years ago around securing network conductivity between hosts in a public cloud and multiple public clouds. We didn't necessarily fully trust the providers that some of these hosts were running in. We also had a lot sensitive traffic flowing between different providers. A lot of  interesting business requirements things of that nature that kind of led us down this path of trying to think about things a little differently and,  building something that was gonna work for our needs, but also still meet the security bar that we had. 

Evan Gilman: It was actually after a conference talk I gave wherein one of the questions at the end was where can I go to read more about this? And I was like, well, I don't know. I don't think there's anything out there really. It's, it's pretty new and I mean, I've looked. I haven't found anything. Come talk to me afterwards. 

Evan Gilman: We were approached by O'Reilly and asked if we wanted to write a book on the topic. I hadn't really been one to have a desire to write a book to be honest. It sounded like a lot of work. In hindsight, it was a way more work than I even imagined it would be. But I felt passionate about the topic and I felt that it was important and that nobody else is talking about it. People should at least be considering it.

Evan Gilman: After that editor approached me, I approached Doug my kind of partner in crime on this stuff. And quite frankly, he did most of the dirty work and the hard parts of, of figuring this stuff out when we went through that project and asked if he would participate. And he reluctantly, I twisted his arm a little bit, eventually, eventually accepted.

Evan Gilman: A lot of people had written about these types of problems, but nobody had really written about them all being kind of related to each other in this bigger picture, zero trust type thing. There was some prior art, but it wasn't like super duper cohesive and, and certainly it wasn't laid out like, okay, if I want it to do this exactly,  what are the things I should be thinking about and how could I accomplish it? I do think like our work was probably the first of that work.

Evan Gilman: I also believe that  in all of the year and a half worth of research that we did leading up to the book, even that I think  had a pretty big impact because other people who were off working on certain slices of this problem all of a sudden were aware that hey it's bigger. And there were people who were thinking about this and like, they start thinking about it, right? You start getting kind of this buildup, you know. And I think today, you know, several years later it's certainly much larger and wider than I ever imagined it would be. I think our work was  just like that small snowball rolling off the top of the hill that was able to get that tiny, little push that was required to bring the attention necessary. And it just grew legs and took off on its own. 

Rick Howard: I asked Doug about how Evan convinced him to join this book writing journey. 

Doug Barth: I think my, my exact comment to him was, "Oh, the book people came by your talk. I understand." I like working with Evan. Evan's super smart. Like he mentioned, we had only scratched the surface of the topic  because we were  building for a startup's needs and like solving problems as they came to us. I thought it would be interesting to  continue the thought exercise of, "Alright, well if we're going to build systems here under this assumption that our networks are untrustworthy, how would we continue to design and iterate on that  architecture?" 

Doug Barth: That was what basically the, what, a year and a half that we've spent like researching and digging into it. Just trying to like figure out what would our answer be if we had to deal with this problem, what would our answer be if we had to deal with that problem, and then trying to educate ourselves on what the broader understanding was thinking here. So we weren't just like making it up in a vacuum.

Rick Howard: I'm a bit surprised that "Zero Trust Networks" is one of a small handful of books that I could find that deals with this topic. After all the concepts started kicking around security circles in the early 2000s. The Jericho Forum started talking about de-perimeterisation as far back as 2004. The problem they were trying to solve was that most of us install an electronic perimeter, a wall that bars access to our digital assets. But once you have legitimately logged in, you have access to everything inside the electronic wall. By de-perimeterisation, the Jericho Forum meant that verifying identity and granting access authorization, what happened away from all of our digital assets. In other words, it would happen outside of the electronic wall. Once granted, the user would get access to the asset they needed. Not all the assets within the perimeter, the U.S. military incorporated some of these ideas into their Black Core Initiative in 2007. Somewhere between then and 2010, the community started to refer to de-perimeterisation as software defined perimeter, or SDP.

Rick Howard: In 2010, John Kindervag, working for Forester, published his essential zero trust white paper that solidified the concept and expanded upon it. That same year because Google got hit by a massive Chinese cyber espionage attack, coined Operation Aurora. Their site reliability engineers rolled out an internal version of SDP as part of a network redesign. A few years later, about the same time that the Cloud Security Alliance adopted SDP as a best practice, Google launched a commercial offering of their internal SDP architecture called BeyondCorp. But let me be clear, SDP is not a complete zero trust solution as John Kindervag would likely point out. There are many things you can do to improve your zero trust posture. But if you deployed an SDP architecture, you would be a long way down the road on your zero trust journey.

Rick Howard: Admittedly software defined perimeter is a horrible name. The concept of perimeter defense is something that we all came up with back in the 1990s and it's never really worked that well. We basically put a firewall between our internal assets and the external internet, which was fine back then. But if hackers crack the hard outer layer somehow, snuck through the firewall because of cleverness or misconfigurations, they pretty much had carte blanche access to everything within which they have done repeatedly for years. The network defender community has uniformly accepted the notion that the concept of perimeter defense alone is a bad idea. So why then would we name the architecture and accompanying technologies that we designed to replace perimeter defense with a similar name? It's a mystery. Here's Barth. 

Doug Barth: Make sure that anytime you use the word perimeter, you should recognize that it has a small amount of  a smell in it. We have a whole industry that talked about perimeter security.  Fundamentally, it's a simplifying abstraction that people would want to use so that they don't have to dig into the details of their actual network. There's value in having those simplifying abstractions, but you shouldn't become  complacent that they are solving the problem in its entirety.

Rick Howard: Software defined perimeter doesn't really establish a perimeter in the traditional sense anyway. It's more akin to the Star Trek notion of a transporter bay. Enterprise crew members arrive at the transporter bay, Chief O'Brien, the transporter operator, checks their credentials and verifies that their mission is authorized. If so, then he sent them to the destination. It's the same for SDP. Users surf over to the SDP portal and request access to a resource. The SDP portal authenticates who they are, and checks if the users are authorized access to the resource. If they are, the portal establishes a connection. We shouldn't call this a perimeter at all. The SDP portal was nowhere near the resources in question. It's outside of the traditional perimeter so to speak. Instead, we should call it, oh, I don't know, how about the internet transporter Bay or ITB for short? I love that name. Cut the check, I'm ready for my 10% commission for providing a better name, but Evan doesn't like the name SDP for another reason. 

Evan Gilman: I hate to use the word software defined perimeter because  software defined perimeter is just, to  the best of my knowledge, like an actual technology. It is something that is authored and shepherded by the Cloud Security Alliance. There is  a spec out there for it. It is an actual,  piece of technology that people use to accomplish things similar to this. I would say that technology, a software defined perimeter technology, is one piece of the puzzle.

Rick Howard: In the book, Gilman and Barth developed a couple of technology concepts that they use to build their system. In one idea, they designed the concept of a control plane and a design plane. Here's Evan.

Evan Gilman: That kind of distinction comes from my personal background in networks where we've been talking about these control plane and data plane concept for a long time and big iron  routers and switches, aggregation switches, and things like that. The idea, there is that you have this, this plane over which all of your regular  data flows. If I'm a healthcare organization and  I have five different services and those five different services need to all talk to each other. When we say data, plane is okay, we're talking about those services and the traffic between those services that's your data plane, and that's the, that's the plane over, which  all of your business logic traffic  travels over and things are done on. 

Evan Gilman: In order to accomplish that, there's a lot of things that have to happen. There's probably some load balancing in between these things. There may be some security enforcement controls that need to be  pushed down into the state. And there's,  things that have to occur in order to realize and control and manage to secure that communication. What you ended up having these various,  points in the data plane that have interfaces down into this control plane. For example, if you have a configuration management system,  which was trying to  chew on some, high-level policy and spit out, for example, IP tables rules. This configuration management system has traffic  amongst its  agents and server and so on and so forth. We consider all of this management stuff, control plane. 

Evan Gilman: Then there is a point at which, information is pushed out of this control plane and into the data plane and that's when it  is realized in your service to surface traffic. This allows you to create different fault domains. If you have a failure in your control plane or something blows up and all this fancy  software and equipment, you have to like configure and manage all of this stuff. The data plane is  unaffected,  by design, because  the things in the data plane are still running and we have just  ceased to update the current state of the data plane. That's not always possible, but that's the desired goal and, that's the high level of distinction between the two.

Rick Howard: Another idea, something they call NetFlow. Admittedly, not a great name either, but hey, we're security geeks, not marketing experts. The idea is that you don't have to limit yourself to the traditional notion for authentication requirements when your SDP solution is calculating, whether or not it will allow access to our resource. Traditionally, when we authenticate, we look for something, you know, like a password, something you are like a fingerprint, and something you have like a mobile phone. Your SDP solution can and should add other data items to your checklist. And it's not a one-time thing either. The SDP solution should do this for every session request. Here's Doug. 

Doug Barth: It's not sufficient to just say that you've given a user and a device, an identity, and therefore, they should always be trusted. Like you want to actually get down to each individual session request. But you want to have some policy engine that's looking at that activity and deciding, is it still trustworthy?

Rick Howard: In the book, Evan and Doug suggest that the SDP system uses NetFlow and other data points to form your zero trust policy. And it should be calculated from as many sources of data as possible. I asked Doug to explain exactly what they meant by being calculated.

Evan Gilman: It can be done in a number of ways one of the things that Doug and I worked on was, an abstraction to allow you to define which services or machines in the data centers should be able to communicate with which other services or machines in the data center. You can declare it at this kind of high level, what has in the past been referred to as like intent-based policy? Um, but at some point you have to enforce it and you have to know how to enforce it and how do you know which traffic is from whom and all that kind of stuff. That's part of what we meant by calculating. So for a very, very kind of simple example, I have an intent based policy that says service X can talk to service Y. But in order to install this into  my policy enforcement which might be something basic like a host based IP tables,  I need to go out and I need to find, where exactly is, service X and Y running right now. How do I go from that to the rules that IP table swans, that's  the level of computation in the middle that the logic that turns the intent into bit level policies that can actually be enforced. We see the fairly recent emergence of authorization languages that are designed to interpret and do some of this computation for you. Your policy in this language might say, you can access X resource during these hours from these locations or something. There was a policy engine was choose on that policy and then what the policy engine knows is, hey, they just made this request. Okay, well, what time of day is it? What did they actually request? Have they been authenticated? Where is the requests coming from? There's a computation there that occurs and they're just handled under the covers by this policy language. It might be that, the language in which you're declaring these policies there's a translation or computation that needs to occur in order to, to massage them into something that your policy enforcement point will actually understand and can use. 

Rick Howard: In chapter nine, Doug and Evan include a couple of case studies. One was written by a Google employee, Betsy Beyer on how Google thinks about zero trust, SDP and their commercial product BeyondCorp. For those keeping score at home, Betsy is also a Cybersecurity Canon Hall of Fame author for a book she co-wrote with several of her Google colleagues called "Site Reliability Engineering." If you want to hear about how Google does DevOps, the "Site Reliability Engineering" book is the how to manual, but I digress. I asked Doug and Evan why they thought they needed a Google case study. 

Evan Gilman: We read a paper that was released by Google about their BeyondCorp architecture. We realized that what they were doing was very, very similar to what we were doing with one big exception, they're securing traffic that was between their users or enterprise users and enterprise applications or corporate networks, so to speak.

Evan Gilman: We were doing very similar stuff, following very similar kind of ideas and principles, but inside the data center for  machine to machine traffic or services, service traffic, and when we read that paper, that was  a big insight. Up till then we had been doing  some conference talks and stuff about the work that we had done personally and, and this different way of thinking about things. And then when we read these BeyondCorp papers, we thought, hey, there's a bigger story here. There's, there's more than just this neat thing that we did.  Other people are seeing it this way too. And it's not just enterprise traffic, like BeyondCorp, it's also data center traffic. We started to connect these dots and realize that, this was bigger than just like that cool project that we did.

Doug Barth: We wanted to  have something that  when a level below the abstract, like topics that the book ended up talking about and having a few case studies that  actually talk about real networks that were built, seemed valuable,  and seemed important considering we didn't have  here's how to go set it up. Here's your checklist to become a zero trust network. You  have to learn from other people's experiences and start,  figuring out how you apply that to your own  actual existing networks.

Doug Barth: One of the things I always found interesting about the Google BeyondCorp case study thing that stood out to me, they have this section about effectively the slog of how they go about  defining the policy throughout their network of, you know, let's look at existing traffic and classify against our policy and then figure out why things don't work and just keep iterating on that. The thing that was really interesting about that and their case studies is just like, It's not  Google magic, that's making this possible for them. It's a lot of hard work by people just analyzing the data they have in front of them and doing  things that  are difficult, but  achievable. And I think that's a good message for people to have with this type of topic. 

Evan Gilman: It helps to  come out of the house, abstracting down into the weeds. You often see this like tech marketing for tech companies where you go and you read the marketing website and you're like, I still don't understand. Tell me what this thing does. We wanted to avoid that. And we were hoping that by including some, case studies or like, okay, here is exactly how a thing works and here is how it aligns with these philosophies or methodologies that we've described in this book. Asking Betsy to do this for us and having BeyondCorp as one of them, it was a really great contrast. The stuff that we worked on was very immature to compare to  the work that was done at BeyondCorp.

Evan Gilman: We wanted to show some dichotomy there. Like here's a really simple, really straightforward way you can go in and do some of this stuff and get some of these guarantees. Okay. Now here's also like a very advanced, like a very mature deployment with the similar kinds of ideas, and here's how that one works. Google did this thing on a corporate network for user access traffic to enterprise apps. Here's how you can see  the different considerations. It's the same ideas and philosophies and, maybe even some similar technologies and approaches, but the way they're applied is very different we hope that we're able to illustrate  those differences. 

Rick Howard: Doug and Evan published this book in 2017. It's now 2021. That's a lot of water under the bridge in terms of research and development and commercial offerings. I asked Doug that if he were to write a sequel, what topics would he include?

Evan Gilman: I don't think any of the fundamental ideas have really changed. I don't think the philosophy has really changed. I think we got it mostly right maybe some of the phrasing,  and strength of the statements may change here or there slightly, but, those things are relatively stable. There's a lot of stuff that we talked about in the book that, number one may have theorized on something that, other people have built, but was not generally available at the time. Or number two,  discussed,  architectural patterns  to accomplish these things that didn't have  names at the time,  that all have, acquired names and, acquired technologies and products that we can talk about those would be great to include in the book. Here are some projects which focus on these problems, here's how they fit together, here's how they solve each of their respective pieces of the puzzle.

Rick Howard: Now I know all of this sounds daunting, Doug and Evan are two really smart engineers. Not only did they design build and deploy their own SDP system, but then they wrote a book for all of us to read explaining how they did it. Amazing. But another way to look at it is that we are not talking about some maybe possible zero trust solution somewhere in the future. According to Doug, we already know how to do this. We just need to take the next steps.

Evan Gilman: The interesting part here is that we actually, as an industry, know how to do this, right? We have internet facing services, machines that are adequately secured, and they're adequately secured because they're internet facing. And we know we expect there to be regular attacks against it. We secure it with encryption and authentication and integrity on the wire and, all of those kinds of stuff. What we're talking about is pretty much the same thing, except now we want to do that to every system. You have forget about whether it's internet facing or not. And here are some ways that you can think about automating it because historically that's the big challenge is internet facing services has been done on a case by case basis. Here we want to apply the same security at scale, across many systems in a way that is controllable and manageable.

Rick Howard: The book is called "Zero Trust Networks: Building Secure Systems in Untrusted Networks." The authors are Doug Barth and Evan Gilman, and they are the newest additions to the Cybersecurity Canon Hall of Rick Howard: Fame.

Rick Howard: And if you are interested in the collection of Cybersecurity Canon Hall of Fame books, plus all the candidate books, and even the best novels with a cybersecurity theme, check out the Cybersecurity Canon website, sponsored by Ohio State University at icdt dot osu dot edu slash cybercanon , all one word. And with "n" end for canon of literature, not two "n's" for machines that blow things up. And, if that's all too hard, go to your preferred search engine and type Cybersecurity Canon and Ohio State University. And congratulations to Doug Barth and Evan Gilman for their induction into the Cybersecurity Canon Hall of Fame. 

Rick Howard: And that's a wrap. Next week, the CSO Perspectives podcast is still on break preparing for season six which starts on 19 July. While we're away, we will keep running my long interviews with the 2021 author inductees into the Cybersecurity Canon Hall of Fame. Next week is Liza Mundy, author of "Code Girls.". The story of the American equivalent effort to the Brits' Nazi code breaking efforts at Bletchley Park during World War II, only the Americans were mostly going after the Japanese codes and the bulk of the work came from American women. You don't want to miss that. 

Rick Howard: The CyberWire's CSO Perspectives is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions, remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design, and original score. And I am Rick Howard. Thanks for listening.