Gathering Data for Zero Trust

Security.

Hi there. Welcome to the Cloud Security Podcast. Thanks for joining us today. Your hosts here are myself, Tim Peacock, a product manager here in cloud. I look after our threat detection products. And Anton Chuvakin, a reformed and tamed former analyst. and member of our cloud security team here at Google. You'll find this podcast wherever podcasts are distributed and on our website if and when we finally do launch it. In the meanwhile, you can follow us on Twitter at twitter.com/cloudsecpodcast. Our guest today is Max Saltenstall, a developer advocate here at Google Cloud. Max, thank you so much for joining us today. We are stoked to have you on the podcast. And I think we will get right into it. So today's topic is Zero Trust or BeyondCorp. Max, what are these terms? What is Zero Trust? What is BeyondCorp?

So this goes back about 12 years or so when Google had to do a fundamental reimagining of how we do security inside our company. And the effort was called BeyondCorp because it was an effort to move beyond a corporate network. We had to go past the idea that You're either inside the corporate network and thus you can get access to the things, and we presume that you are safe, or you're outside and you have no access at all, like when you're working from home or from Starbucks. And we realized this was a problem for a host of different reasons. And so we started changing things. More recently, zero trust has become the meme, the term around a lot of these efforts. And it really just means I don't implicitly trust my network. And I'm a big fan of BeyondCorp. I'm a big fan of zero trust. I do think they both get thrown around too broadly and can be very confusing when people often will say them but mean different things. So it's great to define our terms here and dig into it a little bit.

So this is really the move away from enterprises being a crunchy exterior with a soft chewy inside.

Yes, no more M&Ms, no more eggs. It's about abandoning perimeter security. It's about contextual access. It's about testing each and every time somebody tries to get to a resource, whether that's a website, a database, a VM, and checking, do I actually trust Max enough to let him in right now?

I think the broad definition is sometimes a risk because frankly, in my experience, I've encountered people who say zero trust means you cannot trust anything. And frankly, this is false because you obviously need to trust the zero trust system itself. You need to trust identity. You need to trust endpoint state data. So let's go have a discussion about what else must be reused and ultimately trusted for zero trust system to work.

Yeah, you have to build a chain of trust completely. And with BeyondCorp and the way we've decided to implement zero trust at Google, you do have to start somewhere. So often that means you're starting with a trust in some of the information you have about your people because you've assembled it yourself, having hired them, and some information that you have about their computers, which you're getting from agents. A frequent challenge I get there is, well, what if the agent gets compromised? Then what do I trust? You don't want to place all your trust in just one agent or one data source. But what we do is we're gathering information about the devices that employees are using, and we have information already about the employees, right? I know Max, he's in New York, he works in engineering. And so that gives me a way to design a system that can grant or deny access based on that data. And I trust that data because I know where it came from, I know how I got it, and I have other data sources to corroborate it.

So is it useful to talk about the root of trust in a system like this? Like, what's the real root of trust? What must be trusted, otherwise the whole thing collapses?

I mean, you trust that I'm not an alien in human form feeding information to my overlords in orbit behind the moon, but you have to trust some level of agent-based data about your devices, right? I'm not in everybody's house right now as we work from home checking on their computer, and I have to trust something that I'm getting back, whether that's from Chrome's endpoint verification, whether it's from CrowdStrike or whatever it is. I need that device identity and device metadata, and I have to trust my HR system, right? However I'm tracking all these people and the groupings. Tim says he's in product management. Do I really trust that that's true? I mean, I could go check, but if someone had access to the way we track employees, had that been compromised, that's definitely going to derail my zero trust system for sure.

This would substantially rely on identities being accurate and correct. So that means probably multi-factor authentication is needed. The actual identities should be attached to the right people, and people should be grouped in the right way. To me, this is probably the second Big part of what I would call root of trust for zero trust is identities, not just device data.

Exactly. And the reason I don't just trust Tim to say who he is is that he's also authenticated with a strong second factor so that it's very hard for someone to spoof or phish or otherwise impersonate his identity. And that's an important part of the whole chain of trust in the way BeyondCorp or zero trust implementations should work.

So it sounds like we've really got 3 pieces of trust here, not zero trust. We've got identity trust, we've got multi-factor trust, and we've got device attestation trust. So not zero trust.

Yeah, and I think identity is something I would maybe break out into a couple pieces. Is this actually Max or someone pretending to be him? And then there's, is Max in the right groupings, right? Did he get the right entitlements that he inherited by the factor of being in cloud or being in engineering or being in developer relations? So yes, and I think it's good to point out the second factor that I am definitely trusting the strong authentication of choice. And without that, this whole system falls apart, right? If you have weak or phishable authentication mechanisms, please don't even try to do Zero Trust. You have bigger fish to fry, and you need to do it right now.

This is an excellent point, and I feel like it needs to stand out in the podcast. It's a good one. Okay, so let's look at this as a project that a company, an organization may do. So in your experience, Max, what's the first step in a Zero Trust implementation that increases the chance of its success? Like, what can an organization do in the very beginning to make sure that their journey to Zero Trust is A, successful, and B, not so painful, and whatever else?

I usually give people 3 parallel first steps, which is a terrible answer, but I'm going to be honest with you. So one of them is what we just talked about. You have to have that strong authentication. If you're not doing strong multi-factor auth, don't do the rest of this. It's pointless. Just don't. Number 2, in parallel, 1B, whatever you want to call it, is you have to understand your devices in some way. Sometimes clients come to me and they want to do BeyondCorp or Zero Trust, and they have this very wide open BYOD policy, and people are just using whatever laptops they happen to have at home. And if I don't know anything about the device that's signing into my corporate information, I don't want to trust it at all. And so I'm not going to give that device Any trust. And they have to have some way to either gather information about the devices, put some agents on there, enroll them in some device management, something. And then the third part is picking a really small use case. And the most likely success builds on early momentum. If they come and they want to just boil the ocean right from the get-go, it's not going to work. They're just going to get stalled. They're going to get stuck. They're going to be mired in approvals, or they're going to just be reading documentation for 3 straight months. It's not going to be happy. So I always encourage people to look for a really focused use case. And that means an application that would be not so painful to move over and a small group of people who rely on that application, right? If you're going to take down your payroll processing system that every single person relies on, please don't do that as step 1. But if you want to use some small web app that maybe just this team of 10 or 20 people use once a week or 2, That's a great place to start because you can recover from any catastrophe more easily and you can learn, you can get the comfort level for you and your IT and your security teams in a lower stakes environment before you move on to higher stakes migrations.

That's a very agile approach to this then. You start small, have early wins, and then work your way up from there.

From a change management perspective, yes. From an infrastructure perspective, you really do have to have all the pieces in place, right? Start with an easy application before you've done your strong authentication. No, please don't do that, right? Go fry that fish. So I would say the device data and the person data, sort of the authentication part and the device health part, those have to come first. Then you take an agile approach to larger and larger use cases or scopes, working incrementally, establishing some early wins, building the skills, building momentum, And it's also helpful to convince stakeholders. Sometimes there's some skepticism from inside. And being able to point to a group that says, hey, I'm actually happier now that we moved over because I don't need to wrestle with this VPN software, because I could work from my phone or my laptop, because I could work from that hotel or for that flight or train ride. And you open up more possibilities for people to do flexible remote work in ways that they couldn't always have done beforehand.

So you're suggesting that a targeted approach where you select some users and you select some apps is what we should do to succeed?

I think once you've got the device and the people data really down, then picking just one or two applications to start with that impact a small number of people at your company is the best place to begin.

Okay, so as far as the more practical aspect of the project, promised to share some details on the data you need to gather before you can do Zero Trust. What kind of data is that? Presumably you would need asset data, presumably you mentioned you need strong identity.

Yeah, the other part that we haven't talked about yet is the security policies. So You do need to know the people, right? What groupings they're in. You need to know how they're authenticating and how much do you trust those methods of authentication? Because that might not always be the same. You need to know what the devices they're using because you can't really grant trust to a session unless you know what it's running on. And then you need to have a conversation usually between the application or service owners and the security or IT teams around what are the tiers of trust that we're going to create and which of these different Destinations requires which tier, right? You want to go look at bugs in our current production product? Okay, that requires the highest tier of trust. You want to go see what vacation day is coming up next month on a corporate calendar? Okay, that requires the lowest level of trust. And maybe there's some gradations in between. That's a conversation between humans. It's a policy conversation, it's a risk conversation, and it's a good one to have before you start implementing because everyone goes about this slightly differently. The error I frequently see is that they actually spend way more effort on defining some super fine-grained system. You don't need more than a handful of gradations of trust, but you do need to map each of your applications to one of those gradations and figure out what's the minimum that Max needs in order to go look at this codebase or that database.

That makes a ton of sense, and I can imagine that being both an exercise in bike shedding and an exercise in a lot of spreadsheets. So bike sheds and spreadsheets. People say Zero Trust is hard. Would you agree? Is it hard? What are the places where people get stuck? What's so hard about it?

I think it's hard for some organizations. It depends what they're coming from and what they're trying to get to. As we mentioned, Zero Trust tends to mean a lot of different things to a lot of different people, but I think the starting points are not hard. Understanding your people is something every company has to do because, you know, those people want to get paid, and if you don't know what job they have, you don't know what to pay them. We're already part of the way along that journey. Understanding your devices is something, again, that most companies are doing. There's a couple that have policies that make me scared at night, but for the most part, they are doing it. And the tricky part there is just the integration, right? How do I pull the data I have about people's laptops and move it into that security decision-making system, whether it's BeyondCorp or some other one, connecting those dots? is often the hard part. And it's hard just because they don't know how to do it.

Hmm.

Sometimes they're also doing it for laptops and desktops, but they're not doing it— or they're doing a different thing for mobile devices. And so you have this weird mismatch where I know a lot more about laptops and very little about phones. But if people want to work from both of them, I have a little catching up with myself to do before I can really put them on par. It's a huge benefit for us that we don't really care what form factor is best for someone because it's going to change throughout the day or week. Because we can support them equally. So I think the hardest parts are either getting the information from where it is right now, whatever legacy systems are using, into their Zero Trust solution and into the cloud, or figuring out what are the gaps in our knowledge, right? What do we not know? Oh, Alice over there changed departments last week, but that's not reflected yet in the system. Well, that department change, that job change should reflect the change in authorization and access. We don't have that captured. She's going to have a bad time getting her job done when we move to this system because we actually measure access every time.

Fascinating. So there's definitely cases of companies where, like the old Irish expression, if you're trying to go there, I wouldn't have started from here. But for the most part, people are able to make this migration without too much trouble.

I try to avoid telling people not to go there, but it's definitely easier for companies that are already bought in with cloud identity. with a cloud-native approach for the applications they're running, and with an understanding and appreciation for device management and monitoring.

But would you also say that it's easy as long as you selected a small set of apps and a small set of users? So as long as you chose wisely, your initial project may in fact be pretty simple. Like, you're not going to choose a mainframe app for phase 1. You're going to pick some modern web app internally or in the cloud. So in which case, it would actually be easier, right?

The funny part is once you've picked the app, once you've gotten to that step, it is actually really easy. It's getting to that step that I see being really hard for a lot of companies that I work with. They get stuck, as Tim said, in some bike shedding. They get stuck in endless security conversations around policy. They get stuck in debates about which kind of authentication and authorization mechanics they want to use. The hard part is actually reaching that stage where they can flip the switch for that first application. Once they're there, once they've done those precursor steps, it's really easy. It's kind of so easy that they look back and they think, wait, we're done?

That was it?

You just click the button? And it's laughable.

So that's the experience in my other sort of coverage areas with security monitoring and log collection, log analysis. I can certainly relate. I hear the same tones from this area to the other one as well. As a kind of interesting sort of transition to this, and I don't want to sound completely marketing about it. But another question I sometimes hear from people in the industry is when we launched this Beyond Corporate Enterprise as a product, people started saying, oh, is this what you launched what Google is doing? And of course, we kind of had to explain that just as Chronicle isn't what Google uses internally, BCE isn't exactly what Google uses, but it's built on the same principles, largely by the same people. So how would you answer it? Is BCE the same as Google? No air quotes on podcasts, sorry.

It's okay, we heard them. And I wish it were, and I think one day it will be, but it's not. What I like to say is that BCE was inspired by what we did at Google. What we did is we took many years of development, of mistakes and roadblocks and speed bumps, and we turned that into what we think is a much more streamlined journey for our customers. So I do not want any client out there to have to go through a 6 or 7 or 8-year process to get to Zero Trust. That is not my goal. And what we did with BeyondCorp Enterprise is turned it into a much simpler and easier to activate system, but it also has to be generic. What we built inside was based on the accumulated technical infrastructure and debt that we had over the last 14 or so years and tightly integrated with many of those systems. For example, when we started, We had to solve those problems I mentioned earlier. What are the people? What are the devices, right? We had not solved those problems very well. This was an issue for us. We had 4 different inventory systems, all doing slightly different measurement of the devices that Google employees used every day. We had to spin up a meta inventory system just to corroborate and disentangle the conflicting information. I'm hopeful that most of the people looking to implement BeyondCorp Enterprise Do not have 4 different inventory services. So there's some good reasons why we didn't just deploy what we built inside. We deployed something that could integrate with a lot of third-party tools that companies are already using today, could integrate with other identity providers instead of Google's. And it's continuing to grow and evolve based on what we learned, but also based on what we're hearing from people who use it.

Exactly how a lot of cloud product management goes is we see what Google has done, we understand the problem that we've solved. But we've also solved it over the past N years with this kludge and that patch and these systems held together by some kind of Google duct tape, which I think is usually just goops. And when I explain to people, no, we built this from the ground up for cloud customers to work better, they tend to appreciate it. So on the topic of BCE, what's special about it? Like, why is BCE cool? What's going on with Chrome? What's this IAP business I keep hearing about? What's the deal?

There's a lot of places where I think it's pretty cool. Identity Aware Proxy, or IAP, is cool because it's part of our global infrastructure. And that means that although you might think of it as a single point of failure, it's the same one that Google relies on for so many of its user-facing services, for everything. And that means you're going to be hitting infrastructure that can handle insane amounts of traffic, the biggest denial of service attack attempts the world sees, and redundancy across the entire world. So even if there's, say, an electrical outage across a state or 2, you're still going to be able to get to that proxy that's protecting your important services.

So it's a globally distributed single point of failure.

Yeah, sure, that's one way to look at it. Any cloud provider is a globally distributed single point of failure if you look at it in a macro lens, right?

If you look at it very macro, the planet is a global single point of failure.

Oh, I feel that.

How do we interface with partner endpoint technology? Because you mentioned CrowdStrike earlier. Is there nice partner endpoint integration going on?

Yeah.

So many of the people who come to us looking to adopt this Zero Trust model already have solutions to many of the puzzle pieces, and we don't want them to just throw out the technology integrations they've done and the things they've built up already. So we're working with a whole host of alliance partners to figure out how do we pull in the data you're already measuring about those laptops and phones and tablets and watches and the next things? How do we bring that in and feed that into the Trust Evaluation System so that we can make a smart decision based on the security policies you define without creating more work for you in deploying a brand new agent or in changing the infrastructure you've already built to keep your fleet safe?

So let me ask you a possibly uncomfortable question. So we use Chrome as a data source for endpoint telemetry. And of course, we trust Chrome because we built it.

And it's open source.

Well, there is that. It's easy to verify. So, but you would not say that you trust Chrome more than a partner solution, right? Because otherwise it would look strange. So we trust the telemetry sources on equal ground, Chrome, partner endpoint.

I'm going to actually disagree with the premise of the question. For us, we trust the data from the agents that we built and we deploy on our fleet. For anyone else who wants to run BeyondCorp Enterprise, they're deciding what they trust and don't trust in terms of the data that they're bringing in. The whole point is that you decide what does it require to earn these different gradations of trust and where do you get that data from.

So client is perfectly capable of saying, I trust Tanium, but I don't trust Chrome.

Yeah, sure. You can if you want to.

Okay. That's actually good of us.

And a lot of the time, if they've already built in that, we've deployed it to our entire fleet, it's part of our onboarding, it's something that we're monitoring, we have alerts set up, we're logging everything. Yeah, you've already got the expertise, never mind the trust. Stick with that. It will get you onto Zero Trust faster.

So one more possibly uncomfortable question, because what fun would this be without possibly uncomfortable questions for guests? What's the biggest ZT failure you've seen? Has this like blown up spectacularly for someone? Is there an endless project that somebody's still working on in a basement somewhere, but they're missing their stapler? How does it go wrong?

I can't think of any newsworthy catastrophes. I think that the failure I see is analysis paralysis. So for example, a company that I can't name but is a technology cloud-native global powerhouse company that we've all heard of cannot seem to get their act together to get this deployed. And they have these technology teams, these really sharp technology teams who've been debating it for about 9 months. And I just wonder, what does it take to start down this road. Now I'm exaggerating a little bit because they've done some deployments with some pieces of the technology, but in terms of the whole zero trust thing and really moving over to a BeyondCorp Enterprise or another kind of zero trust, they're just stuck. And I'm not quite sure why, but to me that seems like a failure because I know they could do it. I know they have the capability, they have the technology, they have the knowledge, they have the skilled engineers. I just don't know what's holding them back.

Another analogy from my past life was a security services provider comes to a client and they're discussing monitoring and stuff, and the provider says to the client, give me the list of your critical assets. And the client says, I wish I had it. Okay, fine. So we are on the same page here for sure. But the point is that sometimes certain type of context info that has to be in place just takes a while to gather. So to me, this is not a failure mode as such, but it's kind of, indeed, it's an analysis paralysis failure mode. You're right.

Well, that is it for us on time today. Thank you so much for tuning in and joining us once again here on the Cloud Security Podcast. Your guest today was Max Saltenstall. He was a real champ and put up with all of our relatively kind questioning. Your hosts today were Anton and Tim Peacock. You can find this podcast, and it sounds like you already found it, on Google Podcasts, Apple Podcasts, and wherever else you get your podcasts. You can also follow us on Twitter, @CloudSecPodcast. You can follow Anton, @Anton_Chuvakin and myself @TimPeacock. If you like what you heard today, tweet at us, email us. If you don't like what you heard today, tweet at us or email us. And if we like or don't like what you say, we might even invite you on the show. And we promise to at least ask you interesting questions, not necessarily to be nice. Max, thank you once again for joining us.

Glad to be here.

Thanks, folks.