CloudTrust Initial Made Easy

Cloudtrust initial

AMEET JANI: Hi, everyone. Today, Jennifer and I are very excited to walk you through the BeyondCorp story from Google. We want to walk you through how Google started this journey, how we now enable customers to do it, and how you can get started in a crawl, walk, run function. So let's get started. My name's Ameet Jani, and I'm a product manager here on the Google Cloud team, on the security team focused on our zero trust tools called BeyondCorp. JENNIFER JEREMIAH: And hi, everyone. I'm an engagement manager at Google's professional services arm. That's our delivery services. I look after our key US insurance and payments accounts. So, Ameet, the philosophy and notion of zero trust is one that we're increasingly hearing about in the industry. How do we explain to our customers what zero trust is and why it's so important? AMEET JANI: Yeah, let's take a look at that. There are a lot of great vendors out there that are saying that they're doing zero trust. And I think that if you look at what Google considers really the core components that are required, there four or five of them that are here. The first one is that every zero trust solution really needs a strong identity story. You need to be able to attest to the user. You need to be able to attest the user's metadata. Right? What groups they belong to? What roles do they have? And you need to to be able to start to build up an understanding of the user's behavior. Does the user normally do this at 3 o'clock in the morning? Does the user normally go to this site 50 times and download a lot of files? It's really key to understand all those attributes as part of the zero-trust story. The second part of this is really understanding the context that's around the user's request. In this case, we're saying devices are a key component of that. Is this a corporate device? Is it a personal device? If it's a personal device, it running an up to date OS? Does it have third party solutions on there that we consider really business critical? All of that stuff needs to fit into the model of understanding the context of the request, along with location, and time of day, and all of other things, and session lengths. The third, and I think key, component of all this is what we call a rules engine. If you're anything like Google, you have thousands of applications inside of your enterprise, and you need a way to deploy rules against 1,000 applications without creating 1,000 different rules. And so this simplified rules engine is very key to that story. And then I think lastly is this idea that you should be able to deploy all of your critical data, whether it's applications or VMs, or APIs, all behind a proxy. And the proxy in line to the request is able to look at the context every single time a click is made to get to access data. Is this the right user? Are they still coming from the right group? Are they still coming from a device that's in good state? Do they still match the company policy? If not, let's kill the request? And if so, let's allow that request to go through, no matter where that application lives, whether it's on GCP, on another cloud, or on-prem. It doesn't matter. JENNIFER JEREMIAH: So now that we've covered the general components of zero trust, can you walk through how Google implements a zero trust model on Google Cloud? Google calls this BeyondCorp. Where did the name come from? And as a customer, what is the typical user journeys that you can see? AMEET JANI: Yeah. Actually, the journey started for us about 10 years ago when we were-- it was an attempted attack on Google internal systems. The lessons learned that came out of that were that the network is really an artificial bound of security. Once you're in the network, you have flat access to everything. That was a terrifying learning for us. The other thing that was really key is that we don't care not only what network you're on, we actually don't care about other attributes. What we really want to make sure is are you the right user, coming from the right type of device, under the right circumstances in order to get access to that information? And from that, the idea was you should be able to work beyond the corporate walls. And that got shortened into BeyondCorp. We've taken all of the same tools and all the same learnings, and now we want to expose them for customers to use as well. So in that vein, we've introduced four or five key components that make the BeyondCorp journey possible for you and your enterprise. The first one is what we call Cloud Identity. This doesn't necessarily mean that we have to be the identity provider. Use Okta, use Ping, use Azure AD. It doesn't matter to us. All that matters to us is that you federate all that user's information to us so we can understand the metadata around that user, what groups they belong to. And we can start to build up an understanding of what is normal behavior for all these different types of users. And we can use that to make dynamic access decisions. The second part of this is really having a ubiquitous endpoint. We wanted to make sure that you should be able to be productive from any type of device, whether it's your corporate device, or BYOD, or anything else, as long as we have an understanding of what the security posture of that device is. And so for us, we use Chrome to do that. The third one here, and I said it earlier, was this idea that you should be able to create access rules and apply them at scale across thousands and thousands of different endpoints and applications. For us, we have a system called Access Context Manager that does exactly that. Our best practices and our learnings have shown, create tiers of access. Keep them very simple, less than 10. For Google, we've gotten down to five. And we said, make them so crystal clear that you can just apply them to tiers of applications wherever they happen to be. So classified applications get a high level of rules applied to it. Lunch menus, and bus schedules, and everything else get lesser, non-confidential kinds of access levels applied to it so you can access from your personal mobile device. And again, all of this stuff needs to be able to run through what we call our proxy. And in our case, it's called an Identity-Aware Proxy-- this idea that you should be able to, in line, again, look at all the contexts of all those requests and still calculate on the fly, is this still a good request or not, and do it with near zero latency. And so for us, that's our Identity-Aware Proxy. Those are the moving pieces around the BeyondCorp story. JENNIFER JEREMIAH: So if a customer is wanting to start implementing Google's BeyondCorp solution, it sounds like setting up an Identity-Aware Proxy, IAP, is critical. Could you delve into IAP as well, and also talk about what use cases it suits and what it doesn't? AMEET JANI: Yeah. And I think you've nailed it. IAP, or the identity proxy, really is core to a lot of this journey. Right? And so let's talk through what that is. The first thing is that it sits in front of all of the different types of data and applications that are out there, or VMs or APIs. And the basic idea is you should have to make no changes to your code, or to your APIs, or anything else. The proxy just front-loads all of that. The second part of it that I think is really important is that this is a globally-distributed managed service. And in fact, this is built on the same infrastructure Google uses to deploy YouTube or Gmail. And so you can understand the kinds of latency requirements that are built around the proxy. And it also comes built in, then, with security. So it takes care of all the authentication, all the context checking for you. So you don't need to necessarily do that through your application. It also takes care of more network-centric kinds of controls as well. It terminates TLS for you, and it provides a globally-scaled DDOS protection. Again, this is the same front-end we use to protect our core businesses at Google from state-sponsored DDOS attacks, and we extend that to customers who are using those applications behind IAP. The other part of this is that the proxy needs to be able to protect any type of application or any type of data, whether that's web applications, whether that's SSH, or TCP, or RDP. It doesn't matter. It should all flow through the proxy where we can go ahead and do all those context checks before we forward the traffic on. And again, customers come to us all the time and say, I'm just riding my cloud journey. My applications have everywhere. The proxy needs to be able to distribute and take care of that for everybody, no matter where the application is. JENNIFER JEREMIAH: A common question that I hear from customers is that users are accessing applications from various devices-- mobiles, tablets, desktops. How do we monitor the health of all those devices at the user level? AMEET JANI: Yeah, this is a common problem we found when Google was going through the journey ourselves, and now we're hearing customers tell us the same thing. Users have multiple devices, and how do I make sure that it's the right user using the right device. And what are the attributes of that device? It's not uncommon today for all of us to have a corporate device, a personal device at home that we want to check email from, even our own mobile devices or devices given to us by work. And we need to go to attest to the status of that device before we allow access to systems based on that device itself. And so to solve that problem, Google for itself, and now for customers, has introduced something called endpoint verification. Endpoint verification simply sits inside of a Chrome browser on any OS-- Mac, Windows, Linux, Chrome OS-- or on a mobile device outside of the Chrome browser-- both iOS and Android. And it collects information about that device. And it sends that information on every single request made by the end user. So if I started an app and click around, both my user information, my user session data, and the device data is sent on those requests. And it helps you understand, is this a corporate device? If it is, then I know that it's safe. I can allow this device to do a lot more than, for example, a BYOD device. I still want users to be productive. They can still access Gmail, for example, or any of their email clients. But we don't really want them to get into too much of confidential data with financial information. So you can make that kind of distinction understanding the device posture. And then, of course, you can use that device posture not just in accessing applications but in accessing Saas, for example, with Gmail, or for accessing APIs. You can say, only employees can be able to access public APIs that are out there if they're coming from a device that I trust. And so this information gets reused in many different ways. JENNIFER JEREMIAH: So, Ameet this sounds great for customers that are using Google Cloud's Platform. What about customers that are looking to integrate IAP with their non-Google Cloud platform? Is this even possible, and are there still the security benefits of BeyondCorp? AMEET JANI: Yeah. In fact, I would argue that many of our customers today are doing exactly this. They're saying, yes, I'm starting my cloud journey at either GCP-- Google Cloud is one of my clouds, or even if it's the cloud I've chosen, I still have most of my workloads on-prem. And I want a uniform and a ubiquitous solution for all of my zero trust models. And so you can see all the things we've talked about still apply here. The first thing is, as long as I understand the endpoint status based on endpoint verification and I know about the user, all of that information is sent to the Google front-end, again where we can do all the analysis on the traffic. Is the user doing normal behavior? Is it coming from the right device? Has anything changed since the last click? And assuming everything goes right, and the proxy determines all the rules are matched and nothing looks fishy, it just simply forwards the traffic back to wherever the application, again whether that's on-prem or in another cloud. We have many customers running in other clouds, and they use this solution to solve that problem. JENNIFER JEREMIAH: I think it'll be helpful for our customers to see this in action. Let's go into the Google Cloud Platform Console and start to walk through the tactical steps that are needed to set this up. AMEET JANI: Yeah, I like that idea. In fact, this is a great opportunity to not only do that, but to walk through the baby steps that an enterprise would need to start to transition through to get to a zero trust model. The frequent thing I hear is, Ameet, I buy the zero trust BeyondCorp story. I really understand what you're saying, and I'm sold. But how do I even get started? I have 5,000 applications. Half of them are legacy. I have three different identity providers from all these mergers and acquisitions. And I think that's really the crux and the first step of understanding what's going on. You need to understand, who are your users, and what are the devices that are accessing data, whether they're yours or managed by somebody else? And so I would argue that any customer getting started on this journey should spend a few weeks understanding exactly that. So let's walk through what that looks like. And so in this example, I think it's really important that you understand RBAC comes first and understanding who are in the groups that are assigned there, whether they're on Google, or whether they're coming from Okta or Azure, it doesn't matter. The group membership needs to present, and you need to be able to see are all the right members part of the right groups, and are they here? For example, I can see these are the members of my engineering team. This is really critical because you're going to later on want to create granular level access for these sets of users. And you're going to want to use groups to do that. The other one is you're going to want to get a sense of all the other users in your organization. Is everybody here that's supposed to get access? Are all my employees present? In my world, all my 41 employees are here. But you want a deeper level understanding of those users as well. So here I can see in my enterprise I've got 41 employees. Two recently left the company, so they're suspended. So I get a sense of all the people that are there. Are they using second factor? This is really key. So you can see here Alice is. Many of the other employees aren't. So I can go back and start to nag those employees and say, you really need to enroll in second factor. And you can also get a sense of, what are the types of devices that are accessing the data? Again, maybe they're in your corporate fleet, maybe they're not. It doesn't matter. But you need to get a sense of how that looks. In fact, let's double click on what that is. The second part of this is you should really understand the device status and the device state for all these employees. Here you can see my devices running an up to date version of macOS. It's a company device. You can see I have other BYOD devices that are in here. That's a concern. And I have some that are out of date. This is terrifying to me. Nobody should be accessing with 10.14.6. It's got a known bug in it. And so you can start to passively watch all these trends over a course of X weeks and understand, what does the fleet look like, and what is the health of the users that are accessing my infrastructure, so I can use that to make rules later on. JENNIFER JEREMIAH: So these rules-- how granular are these security rules that we're setting up? AMEET JANI: Yeah. Everything that you've seen-- all the attributes that you've seen, plus device attributes, and location attributes, and time of day attributes could all be used to make the kinds of access rules. And then you can apply them against applications. So let's walk through. Now that I've gotten a sense of what my data set looks like-- who are the users, what are the groups that they're accessing from, what are the devices? Let's get a sense of how we can use exactly that information. So you saw that I got a sense of make my corporate fleet. And I understand the kinds of OS that they're running and are they corporate devices or not. Let's codify this in rules. So here you see I've already created three rules. And they're called secure device-- which may be a corporate device. I have a contractors tier, which is a device I don't control. And I may have BYOD-- again, a device I don't control but I want to allow access. And you can also geo rules, and IP rules, and et cetera. So here you can see for company rules I can get a sense of what are those policies. I've really insisted on screen lock. I want to make sure that I've marked it as a corporate device. And I want to make sure that it's wearing the latest and greatest OS versions for both Windows, Mac, and Chrome, because by company policy all these devices should be updated. For contractors, I don't necessarily control that. They may be a couple of weeks behind in upgrading, and I can get a sense of what that looks like here. This screen lock is enabled. It has to be approved by me. And for BYOD, I just want to make sure screen lock is enabled. Because somebody is going to use that device to check email. And I want to make sure that if they turn around at Starbucks, for example, that they don't necessarily have that machine swiped and somebody can just access that information. So that's, in essence, what you would do with those rules. JENNIFER JEREMIAH: Great. And what are the types of applications that make good starting points for this journey? AMEET JANI: This is actually the core of what every customer always asks me. They say, I buy the vision. Yes, I can go and understand my corporate fleet and my health of my devices. But I really don't even know where to start. And so some of the best practices we've found from our Google experience, and what we tell our customers, and where we find we have success is really do two things. One is you can start with any type of application, but starting with web applications gives you the biggest bang for the value. A, they're meant to be deployed on the web. B, they have a subset of users who need to access them. So you can go ahead and find out is there a subset of HR contractors, for example, who need to access this? Are there contractors outside of my org that I don't want to give VPN access to, but they can access only one application? These are great sorts of proof of concept applications that you can use to really test out the zero trust value. And again, you can do this all without necessarily turning off the VPN. You can use it to test it out and trust that you believe it, and then you can go forward from there. So let's get a sense of what that looks like. You saw that I created the rules previously with Access Context Manager. Now, let's come in and see how we can apply those rules against applications. So again, the Identity-Aware Proxy comes up. First thing you see is that you don't necessarily to apply them against just Google Cloud resources. They can be deployed against any resource. And here you can see I have web applications. This is in essence a dashboard all the applications I have in my environment. You see some of them are running on GCP. I have some running on AWS here. And I have some running on-prem. And the idea is it doesn't matter where they're running, you want to create a uniform dashboard. The same is true, by the way, of RDP, or SSH, of TCP sessions. I have all these resources located all over the place, but again, I want to create uniform access to those resources. So let's actually walk through what an example of that looks like. The first one is I have a compensation application. It reveals financial information about my employees and other kinds of things. I need to make sure that only members of the HR contracting group should be allowed to access this. So you can see here I said HR contractors can come in and access it. But they can only come in if they're accessing it from what we consider a secure device. If you remember, we previously set what that means. We want to make sure that this information can never leak, and the devices have to be safe devices. And so now only six members of the HR contracting group coming in from corporate devices can see that. Here's another example where we have a Jira application. And we want to make sure all the employees inside the company can see project statuses and things like that. You can add that rule as well. You can say anybody who is an authenticated and legitimate company user, meaning they're coming from the right domain, should be able to access this application. Again, but they need to be coming in from at least a device that's running a minimum security trust value. Here again, screen lock is required. So they can access this application. And then, of course, we can apply this at scale versus other things. So let's get a sense of what that looks like from an employee's point of view. Here's Bob. Bob as an employee. Instead of logging into a VPN and then navigating to the right application, they fire up the browser. They just enter the URL of the Jira application, and they're logged in. It was just like they would access Gmail or any type of SaaS application. Internal systems are now easy to access for employees, but you're not reducing the security posture. In fact, you're strengthening it by saying only these users from this time of day should be able to access this application. And so that's a really key component of the zero trust story. JENNIFER JEREMIAH: OK. So now that we've selected and we've secured our key applications, is that enough? AMEET JANI: Actually, I would argue there are steps that are even more important than anything we've talked about. And we have it here listed as step four, but I think you could even think of this as step zero in all of this. It's a well-known fact that numerous studies have been published that the biggest attack vector, especially the most successful attack vectors against your enterprise, are phished credentials. And so I would argue that session controls and second factor are really key to this entire story. And so we won't touch on session controls here, but it's really important understand, if somebody is accessing highly confidential data, maybe those sessions should be 10 minutes, or 20 minutes, or one hour. They shouldn't be 24 hour sessions. And the same will be true for second factor. Here we'll show you an example of what that looks like. So at Google, we really, really recommend that second factor be there. Second factor is better than no second factor, of course, but we really push this idea of FIDO keys. So here you can see for my applications, I'm going to say I'm enforcing second factor, and it's going to start in two weeks so I have time to nag everybody. Any new employee that joins has one week to be able to register their MFA or get the key in the mail, if they're not in the office. And for us, we're saying security key is really the best story that you have. Right? It doesn't matter-- OTP codes are being phished. There are many public examples of that. And so now I've enabled for all the applications in my enterprise this idea that they require second factor to get access to the applications. I can go one step further and create granular levels of session control as well. I can say, for example, that all confidential data should have short session lengths. My cafeteria menus are not confidential data, and so it's OK if they don't require second factor or if the session lasts 24 hours. I think that's really step one of this journey. The second part of this is actually, I think, more fundamental. We've talked so far about different types of application controlled by the data. Think about applications with debt, with confidential information, or VMs that can shut down environments. But really, the key that's important here is that you protect access to the production systems themselves. Think about this idea that somebody will deal to log into your environment and start shutting off VMs or containers that are running really important data, or that they can come into your identity systems and just start to create identities that you don't control that now have backdoor access to everything. And so what we really say is that the zero trust BeyondCorp model should really extend to your cloud consoles, your administrative consoles, because that's really bread and butter security to your company. JENNIFER JEREMIAH: OK. So SecOps and networking are going to be critical to implementing the BeyondCorp solution. To recap our key steps, it's critical to, number one-- understand to your users are and what is the inventory of devices that are being used. Number two-- get granular with your security by setting up context-aware access level controls. Number three-- identify your POC apps. Web applications that have a common group of users make a simple place to start. Number four-- strengthen user authentication through practices like second factor authentication. And number five-- protect your internal systems. AMEET JANI: Yeah. I think that's a perfect encapsulation of everything that we've talked through so far. It's a great place to start this journey. I know the journey to zero trust seems overwhelming, but this really is a great list to say, let's at least crawl, walk, run. Let's start with the crawl phase. These are the great steps to do it. In fact, there are numerous customers that have already started this journey that are publicly referencable. There are thousands of Google customers that are now starting this journey. These are the public ones. Let me give you a couple of examples to show you the different types of use cases customers have. Last year, Airbnb was on stage with us, where they talk through this example of they have contractors who are not Airbnb employees accessing key customer service applications that are hosted on AWS. They don't want to give them VPNs. They don't want to build an authentication system. This BeyondCorp story provided an easy way for it to front those AWS hosted applications for those sets of users. Another example is Home Depot. Home Depot has 400,000 users, including the ones on the store floors. The idea should be that they're seeing confidential inventory data. This is core to what Home Depot does. We need to make sure the devices they're accessing from, the locations that they're accessing from are relevant and stay safe. And as the employees that work in the store are sometimes transient, we need to make sure that when they leave working for this company that you can shut down access for those users. JENNIFER JEREMIAH: And of course, Ameet, it's important to include Google here. Google was the first consumer of BeyondCorp. It's our homegrown way of securing our systems. Thanks for tuning in. We hope that you've learned a little bit more about Google's BeyondCorp and IAP. You now have the critical building blocks that are needed to start setting up this important security service. And you've got product managers and professional services organization here to help you. Thanks.