Google Cloud Security Podcast: EP59 Zero Trust: So Easy Even a Government Can Do It?

Full Transcript

Listen to the full episode here. A slightly modified transcript is included below.

‍

Timothy Peacock: Hi there, welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself — Timothy Peacock, the product manager for threat detection here at Google Cloud — and Anton, a reformed analyst and esteemed member of our cloud security team here at Google.‍

‍‍

Timothy Peacock: Anton, we're back to zero trust today. 

‍

Anton Chuvakin: Yes, very much so, and it's a fun topic. These are very popular episodes. This time, we're going to mix zero trust with (drum roll) the government.

‍

Timothy Peacock: That's not a popular topic. 

‍

Anton Chuvakin: Oh, we haven't touched it yet. So, at this point, it's going to be about zero trust and how you, as the government, can (wait for it, wait for it…) quickly adopt zero-trust thinking and architecture for its IT environments. How exciting is that? 

‍

Timothy Peacock: Well, this is exciting for lots of reasons. I think it's exciting that we made it a whole year without talking about Uncle Sam, too. I think it's really exciting because a blog post by my former colleague was all about how they're never going to do it, and I thought that was interesting. But the conversation we have today is pretty wide-ranging. We touched on a lot of zero-trust topics, and we also got into an interesting discussion around MFA, and we have a guest today who disagrees with you quite forcefully at one point, which is great. I love when people disagree with you.

‍

Anton Chuvakin: That's correct. And I am almost always gentlemanly about it, am I? 

‍

Timothy Peacock: Oh, for sure. A model of a former analyst. Well, with that, let's welcome today's guest. I'm delighted to introduce today's guest Sharon Goldberg, CEO and co-founder of BastionZero and a professor at Boston University.

‍

Defining Zero Trust

‍

Timothy Peacock: So, Sharon, I want to start off today's podcast. We're talking about zero trust. Zero trust is, like many things in security at this point, now a buzzword. First, does the term have meaning to you, and if so, what does it mean? 

‍

Sharon Goldberg: It definitely has meaning for me. It took me a really long time to figure out what it means. It's really interesting, actually. I was looking at my records, and I realized I was a moderator of a panel in 2015 about zero trust. I ended up changing the name of the panel because I had no idea what zero trust meant at the time. But now, I understand.

‍

Sharon Goldberg: Zero trust has to do with authentication. I think it's a question of how do you authenticate users and how do they prove that they really are who they say? — that's the really narrow definition for me. It has to do with eliminating long-lived credentials, so not giving someone access to something they can hold onto forever and potentially walk away with. In other words, it's no long-lived credentials. No long-lived SSH keys. No IAM roles that they're holding for years at a time and they could potentially take with them when they leave. No VPN keys that are sitting in some kind of certificate they can walk off with when they leave the organization or move to a new computer. That's what zero trust means: eliminating those long-lived credentials. 

‍

Sharon Goldberg: The other thing I think zero trust means is that just because you can access one part of the system [that] does not mean you should access the whole system or other parts of the system. It's this idea that you're constantly reauthenticating yourself to a system. Every time you want to access any resource, you have to prove that you are who you say you are and that you really should have access to that resource. 

‍

Sharon Goldberg: We can keep talking about this in this conversation; the term has expanded a lot. But to me, it's really around authentication and making sure people are properly authenticated and authorized for accessing whatever they're supposed to be accessing.

‍

Anton Chuvakin: So, it sounds like you are anchoring zero trust to authentication primarily. Like, multifactor and other things. 

‍

Sharon Goldberg: Yeah, I would anchor them for sure. 

‍

Anton Chuvakin: How would you frame it as "zero trust is"? And you have to answer. 

‍

‍Sharon Goldberg: Zero trust is the absence of long-lived credentials and the requirement that users authenticate themselves each time they want to access. But I also want to say that “zero trust” is a really interesting word. You would think that it means we should trust in zero things — that there's nothing that you need to trust for security to work. That's what it sounds like. And that's why in 2015, I didn't understand what zero trust meant, and I ended up changing the name of my panel. I didn't know how to moderate a panel on that topic. 

‍

Sharon Goldberg: What we're working on right now at BastionZero is that idea. We want to get closer to this idea of trusting zero things, not trusting some specific thing. Because for the way I define zero trust, you could have an SSO system with multi-factor authentication, and that would get access to whatever you're looking to gain access to. That would be zero trust according to the definition that I just gave you, but that's not zero trust in the sense that you're trusting in zero things. The thing you're trusting is the SSO mechanism, the actual SSO provider. You're trusting that provider to check people's passwords and if you have device context, check that the device context is correct and that they did multifactor authentication properly. All of that is done by the identity provider, the SSO provider. You're not trusting zero things in that case — you're trusting the SSO provider. 

‍

Anton Chuvakin: Well, John Kindervag, who is the guy who created the term, argued pretty violently that you do. I want to strive for trusting zero things. We had almost the same arguments except for the opposite sides. I was trying to convince him that zero trust means trust, and the identity provided trust in the device data. His position was, "No, actually, you do need to aim at the situation where you confirm you validate, but you don't blindly trust even the identity provider." 

‍

Anton Chuvakin: So, to me, this doesn't resolve. This is an interesting discussion that people are having in the industry. 

‍

Sharon Goldberg: I would disagree with you, and I would agree with him. The idea that you have to fully trust the identity provider — that's a good thing to strive for it: All you have to do is trust the identity provider — is still creating a single point of compromise where the identity provider has extreme power over your infrastructure. I don't know if you guys saw this 'cause it was part of the SolarWinds incident that was maybe less discussed, but the adversary was able to compromise the SSO provider and issue tokens for itself to whatever resources it wanted. In a sense, the identity provider was compromised. At that point, access to everything is possible for the adversary because they own the identity provider. 

‍

That is an example of this definition of zero trust not being sufficient because you were not trusting in zero things — you were trusting in the identity provider.

‍

Sharon Goldberg: I guess where I'm going with this, for me and for what we're building at BastionZero, [is] the ideal is that you don't fully trust in one thing, [and] you have some way of recovering from a compromise of the authentication system. That's what we have at BastionZero. We have this multi-root zero trust where instead of one route of trust that controls authentication and authorization, you have multiple. If one of them gets compromised, you still have the other ones there, and you don't have a full compromise [of] your system [like] the way you have with SolarWinds. I would be, again, disagreeing with you and agreeing with him. 

‍

Sharon Goldberg: Although, note that what we're doing is not the standard in the industry. It goes one step beyond what most people are doing or trying to do at this point. It does come close to a system where someone will put the VPN, and then they'll also have a multifactor authentication or hardware key on an individual Linux machine. What they're doing is they've put multiple authentication systems in place before someone can get into the Linux machine. They've got to first get into the VPN, and then they've got to get into the Linux machine with the multifactor authentication. You don't have this risk where one thing gets compromised, and everything fails.

‍

Sharon Goldberg: I think we should be striving to trust in zero things, but that is not what zero trust means in the industry. Maybe it will in a few years, and that's what we're trying to do at BastonZero, but it's not the case [today].

‍‍‍

Exploring the Zero Trust Federal Government Memo

‍

Timothy Peacock: Before we get any deeper on what "zero" means I want to switch gears and talk about this federal memo. Sharon, we were really impressed with the blog posts you put out analyzing the White House memo. What caught your eye about it? Why did you decide to write about it?

‍

Sharon Goldberg: I was so excited when I saw it. You can look at my Twitter, and there's me tweeting, "Oh my God, I can't believe this," and, "I have to write about this." Then, four hours later, I'm done writing and dropping this tomorrow. I was so excited because the first line of the memo was the federal government — I'm not quoting this correctly — but it was "the federal government can no longer depend on perimeter-based defenses for security." 

‍

Sharon Goldberg: It goes on to spend the whole memo talking about how VPNs are not good enough. I was like, "Whoa." Maybe it doesn't sound surprising to anyone [now] after having read that memo and everyone talking about it, but in the beginning, in the middle of January, that was shocking to me to see someone saying, "No more VPNs. VPNs are not enough for security, and we can't rely on them." I kept reading it, and it just kept getting more and more intense. It starts to say, "Applications should be available on the public internet. Don't even put a VPN there. It's got to be secure enough so that you can access it without a VPN. Do the work to make your application so secure that [it doesn’t need to be] behind the VPN." 

‍

Sharon Goldberg: I keep reading, and it starts talking about DNS security and how DNS has to be encrypted. I start jumping out of my skin because I'm a big DNS geek, and there's been a lot of debate about whether we should encrypt the DNS or not. This is a very contentious topic in the network security world, [but] the memo's like, "[You] need to encrypt your DNS.” But AWS doesn't even support that today! So, if I wanted to encrypt my DNS traffic as an AWS customer, I can't do it. It's not even a possible thing for companies that are building the public cloud — they can't do this right now. I was reading this memo, and I was like, "Wow, this is so many steps ahead of what's happening." 

‍

Sharon Goldberg: The last thing that caught my eye was [that] it talks about the federal government putting bug bounties in place. I teach a class at BU on information security, and I have [twenty to twenty-one-year-olds] learning InfoSec and learning hacking for the first time. I have to scare them and say, "You know, there's the CFAA. If you do something wrong [when hacking into a system] you can get prosecuted." Then, I tell them the story about the MIT students who presented at Black Hat when they hacked the subway in Boston. The FBI came to their talk and pulled them off the stage. I tell them that story so that they don't do something stupid. This is still something I have to do, and I've been doing this for twelve years because we often see hackers prosecuted for doing security research. 

‍

Timothy Peacock: Like here in Missouri recently. 

‍

Sharon Goldberg: And it happened a few weeks before the memo came out by a government in Missouri. 

‍

Sharon Goldberg: I was reading this, and I was like, "Finally, there's something that we can point to where the government said that bug bounties are a good thing," and, "Security researchers examining public infrastructure and providing feedback is a good thing." We've been saying that in this community for twenty years, but seeing it from the government was like, "Yes, finally!" Hopefully, the next time there's a lawsuit or something, people can point to that and say, "Look, the federal government itself is saying that this is something that researchers should be doing." 

‍

Sharon Goldberg: I thought that there were a lot of things in there that were pretty significant across the board in different areas, by the way, like those latter two things: bug bounties and DNS security. I don't think those are zero trust things, but they're really cool security things. 

‍

Timothy Peacock: I'm surprised to hear bug bounties are a hot new thing for the federal government. In college, my buddy would get bug bounties and then buy Rams beer with [them] for us at the bar. That was a long time ago. Is the federal government just talking about that now? 

‍

Sharon Goldberg: I'm not fully up on what's going on. I have friends that are cyber lawyers. There are still cases that go to court about someone doing security research and violating the CFAA or violating the DMCA, the digital millennium rights act, which is basically copyright on digital goods. That still happens, and there's been a lot of effort from different groups to normalize the idea of bug bounties, but I hadn't seen the government talking about it before. In Missouri, it was the government that went after the reporter who did an HTML view source and found something.

‍

Sharon Goldberg: To see that coming from the government, I think is great. We're not necessarily going to see a change to the CFAA, but this is an agency actually saying something. I believe that should hold some weight. It's nice to see after all these years. 

‍

The Impact of Recommending VPN Deprecation

‍

Anton Chuvakin: One other thing that [caught] my attention [was] that they are talking about deprecating VPNs. When I had my first encounters with this concept many years ago, zero trust was replacing VPN with not having a VPN. It sounds like the government discovered that the zero-trust network access — what Gartner calls it — ZTNA is essentially a VPN replacement.

‍

Anton Chuvakin: So, what's your take on that? Are they saying you should turn off VPNs now, or are they saying be on the path? Because it's a long journey. It was a long journey, even for Google. What's your take on this whole idea of deprecating VPN authentication? 

‍

Sharon Goldberg: There's a requirement in that memo that says that each agency needs to identify one internal application behind the VPN and take it out of the VPN. Just one. But what they're doing there is they're trying to insist that people actually build the application securely enough to bring it out from behind the VPN. That way, they will have had the experience of putting something on the internet and not behind a VPN. They've got that architecture in place, and they can start migrating things off the VPN. 

I think that what's being advocated for in this memo is this BeyondCorp approach, or this idea you need to authenticate into the specific applications or specific targets into specific roles and not just into a network or a private network. I think that they're saying stop doing that. It makes sense because if you read the broader news around this announcement, it talks about this being a reaction to the Colonial Pipeline ransomware, which I believe was the result of an old VPN password [getting compromised]. The way that Colonial Pipeline was infiltrated was [through] some long-lived VPN password. It was some password that nobody knew was around or had forgotten about, the attacker found it and they got in that way. If you can get access to a VPN, from there [you can] travel through the infrastructure and get into all different kinds of places where you shouldn't be. 

‍

Sharon Goldberg: That's the opposite of the BeyondCorp approach, where you have authentication into individual applications. Imagine if there was an individual application for whom the password was compromised. It should not be the case that if you stole that password, you can own the whole infrastructure. I think that they're saying that this network-based access control is no longer viable, and it has to be application-based access control or target-based access controls. Are you logging in to a Linux server? What account are you using? Are you logging into a Kubernetes cluster? What role are you using? Are you logging into a website? What username and password did you use? Not "are you in the right IP space" anymore — they're strongly coming out against that.

‍

Timothy Peacock: Yeah, that's fascinating. It's so funny to appreciate this as such a sea change. In my mind, that's how applications work. It's fascinating as we look forward to this. What kind of challenges do you think the government [will] run into [while] doing this? What's going to be hard for them in particular?

‍

Sharon Goldberg: Oh, it's going to be very hard. 

‍

Anton Chuvakin: I think you win the understatement of the year prize for this — you're just not trying very hard. And you're [easily] getting the understatement of the year prize for that. 

‍

Sharon Goldberg: I don't really work with the government, so I don't know all that much about this. I will say it's an interesting situation because when you want to work with the government, you have to have something like a FedRAMP certification and all these sorts of certifications and navigation and understanding of how to work with the government. So the government can't necessarily buy things off the shelf because they may not have the right certifications. If you think about it, it's not only that they're a very large organization with a lot of bureaucracy and a lot of people in a lot of legacy systems, but even the set of products that they can use is limited. The set of places that they can deploy and do things is limited. I think it's going to be really challenging. 

‍

The Future of Cloud Security

‍

Sharon Goldberg: One of the things that if you look at the memo, you see there are these very small, little milestones that the agencies are asked to achieve — for instance, taking one application off the VPN — [and] the memo [recognizes] how hard this will be. But I also think that the memo is not necessarily only for the government. I think it is meant to drive change in the whole industry. 

‍

Sharon Goldberg: Let me give you a very concrete example. I mentioned this before: You want to encrypt your DNS. Do you want to go to AWS now and encrypt your DNS? No, you can't. If the government wants to use these cloud providers, they're going to insist on encrypted DNS traffic, then the cloud providers have to provide the ability to encrypt DNS traffic. Then the rest of us can enjoy the existence of this technology. 

‍

Sharon Goldberg: Something that I studied as a professor was the deployment of security technologies. How do you kick off advanced security technology deployment? A lot of times, that has been done by the government mandating [the deployment of certain security technologies] and therefore, forcing vendors to implement those technologies so that the government can buy their products. Once that happens, the rest of us can start to use these technologies. I think that this is an additional function of the memo: It's not just about what the government can do, but what vendors will need to provide and what the industry will start doing.

‍

Timothy Peacock: That's really interesting. Could you say more about that? Government making people be more secure that then drives more security? What does that evolutionary journey look like? 

‍

Anton Chuvakin: If I may offer a quick comment — and it's amazing because I see the logic behind it — if a standard is adopted and it spreads like the early MITRE stuff that started in the government, it [can] become a community standard. That, I see. Maybe Sharon has more possible channels for everybody to become more secure? 

‍

Sharon Goldberg: Well, there have been a couple of technologies that have had this type of journey. I'm not a hundred percent sure about this. I should have prepared more, but I believe you can use the example of IPv6. I think you can use DNSSEC as an additional example.

‍

Sharon Goldberg: By requiring the government to operate within these technologies or support [them], [it] forces vendors to start to support them. I'm struggling to remember examples of this, but when I was doing my Ph.D., we talked about [the] deployment of security technologies and how the US government has driven the deployment of a lot of security technologies over time by mandating the use of certain technologies. I think this is another case of that. At least, with email encrypted email — that's the most obvious one. It's not that easy to find encrypted email or encrypted DNS supported by vendors today. 

‍

Sharon Goldberg: They talk about encrypted email in there, by the way, which is really interesting because it doesn’t say what technology would be used for encrypted emails. I don't know what they're thinking of or what protocol this is exactly. But, regardless, encrypted email and encrypted DNS are not easy to buy and implement for the average organization, and so if the goverment starts requiring them it will become easier for the average organization to gain access to them as well. 

‍Timothy Peacock: The other good example that comes to my mind of [the] government pushing [a] security thing that then trickles to the community is the push on the Software Bill of Materials (or SBOM). Now, that's the other thing that was big in the recent timeframe. I think that's an awesome example of transparency. And the simple act of documenting what you use drives people to better outcomes. 

‍

Anton Chuvakin: That makes sense. Of course, this also happens to be one area where I feel it won't work [without the government]. It's not just the government does something well and everybody copies — which happens infrequently but if it gets on, it [gets on] — I feel if they don't do it, nobody does it. This is a separate fun topic, which we'll explore in a future podcast, I'm sure. But let me try another fun question to ask Sharon.

‍

Anton Chuvakin: My impression is that the lessons that are learned when the doc was created, when the memo was created, are also useful to non-government, normal companies who are implementing a zero-trust strategy. Can you give us three or four lessons that others can derive from a doc? What are useful things you can implement if you're pursuing zero trust? 

‍

Recommend Zero Trust Strategies

‍

Sharon Goldberg: Let's start with the first. The very first lesson is to log into applications, not into networks. That means that if you're building some sort of internal, maybe you have a Grafana server. So you need to have people authenticate into the Grafana server and not just stick it behind a VPN and have it otherwise open and let people come in however they want. Similar example: You have a Linux server, [and] an SSH key to your Linux server. You do not want anyone to be able to get into that Linux server [just by virtue of being on the VPN]. You want to control access to that [Linux server] and not just trust that as long as it's behind the VPN, everything's going to be okay. So you don't want to have a server holding the SSH key to another server sitting in a network behind a VPN. That is not acceptable, according to this philosophy of zero trust. Log into applications or targets, not into networks. That's the first thing. 

‍

Sharon Goldberg: The second thing is the thing that everyone knows: multifactor authentication. Not very controversial. What is interesting and controversial is that the memo is just super down on the TOTP protocol, which you probably know because you use it with your Google Authenticator: It's the six digits that you get from that app on your form. The memo really hates that as a form of authentication, and it's pushing for hardware keys. 

‍

Anton Chuvakin: So, that's what I call a 1% or rich person's problem, right? 99% of them are not two-factor, and a big part is SMS. And they're going to step on the people using apps for MFA? [Move them to] the hardware? I'm sorry, this is stupid! 

‍

Sharon Goldberg: No, I mean, that was aggressive. Okay, so SMS-based two-factor authentication must die. I think we can all agree. And it's not dying. It's still there. Banks still use it. It drives me crazy that you MFA into your bank with your phone [using SMS]. But it's still that way because the banks don't think regular people can install an app on their phone or something. I don't know. That must die. 

‍

Sharon Goldberg: But they're also negative on the TOTP. I don't think that recommendation is going to have much of an impact, but it makes sense. There [are] so many attacks that have come out about TOTP. They're a little bit more exotic, but they exist. We can debate how to implement MFA, but I don't think we should debate whether we should have MFA. I think that we can all agree SMS-based MFA should die. So use something other than SMS-based MFA for MFA — that would be my second lesson. 

‍

Sharon Goldberg: [For] my third lesson, this is a very interesting requirement, and I would say again — like you said, Anton — a rich person's problem. The memo talks about device context (validating that users are actually using the right device). That is a really hard thing for organizations to do because they have to manage the devices and make sure that they have a full inventory of their users' devices. They can make sure that Sharon is on this specific laptop that was issued to her. Another example of why this is hard: Yesterday, my laptop died, and I switched to my previous laptop. With device context, maybe I wouldn't be able to log into my corporate accounts anymore. 

‍

Sharon Goldberg: I guess the last thing is just basic network security hygiene. The memo talks about [integrating] TLS into your applications. Great, everyone does that. It also talks about TLS between systems that are on the same internal networks, which is interesting. That's something to think about. Then, of course, the last point is around DNS: You should be doing encrypted DNS in your network. That's another interesting thing to think about.

‍

Sharon Goldberg: Of all these lessons at least the MFA and VPN piece is something that you can start to think about right away. 

‍

Timothy Peacock: This is fascinating. The memo clearly has a lot of good meat in it. Listeners, we're going to include the link to the blog post in the show notes and the Twitter release, and the LinkedIn posts we do about this. Sharon, we're about out of time, and I want to ask our traditional closing questions first: Do you have one tip for people to improve their security posture? 

‍

Sharon Goldberg: Okay, so I'm going to go with my one tip being MFA. I love MFA. If you can put it in, put it in. If you haven't turned it on, turn it on. That would be my one tip.

‍

Timothy Peacock: And two, do you have recommended reading? I think, as a professor, you're best suited to answer that question than all the guests we've had so far.

‍

Sharon Goldberg: Well, I wrote this blog post analyzing the government's memo on zero trust and 30,000 people read it within like 24 hours, which was crazy. So you can go read that. 

‍

Timothy Peacock: Amazing. Sharon, thank you so much for joining us today. It was a real pleasure. 

‍

Sharon Goldberg: Thank you. 

‍

Anton Chuvakin: And now, we are [out of] time. Thank you very much for listening. And, of course, for subscribing. You can find this podcast on Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts.

‍

Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter at twitter.com/cloudsecpodcast. Your hosts are also on Twitter at @anton_chuvakin and @_TimPeacock. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode.

‍

Anton Chuvakin: See you on the next cloud security podcast episode.

‍

‍

‍