Enable Zero Trust Access Controls for your Web Apps, Infrastructure, and APIs (Cloud Next ‘19 UK)

[MUSIC PLAYING] SAM SRINIVAS: Hi, everyone Can you hear me? I’m Sam I’m from product management in Google And I’ll be telling you about Zero Trust access today And I’ll be joined shortly by Adam and Gagan who are here Adam is from Deliveroo And he’ll be telling us about his experiences implementing some of the stuff I’ll be talking about And Gagan will actually be showing you what this stuff looks like So Zero Trust, actually– the agenda which we’ll follow, basically, is I’ll tell you about a new cloud security model, which is like what’s the Zero Trust about, what are the trends costing us as an industry to move in this direction And we have some tools, I’ll tell you a little bit about the tools Google has And then Adam will talk to you about Deliveroo’s experience, both the good and the bad And in fact, as I finish, Gagan will come up and show you these tools in action And then Adam will show you how they implemented it And finally, we’ll come back and talk a little bit about how you could get started on this journey yourself So the problem today is that the reason you build information systems is for people to access them So access is sort of a central existential thing And today the distinction between access, and remote access, and all are just going away Because on one hand, users have left the building They work from everywhere But often applications have also moved So you might have moved the application to a cloud You might be using a SaaS Obviously you’re going to have a bunch of on-prem And furthermore, employees are of many kinds– or users, rather So you might have a contractor who sits in your office, and should they get the same access as an employee does? Or you might have an employee who sits in your customer’s office and works And they need to get access to all your information resources And so basically we need a solution for these And of course you have situations of people putting their own devices Like a contractor might come with a laptop, needs to access your information system What do you do? So the old paradigm doesn’t work anymore So there are many, various words for this It’s called perimeterless and so on Actually that’s probably a misnomer It’s about the perimeter shrinking You want to keep the perimeter only around your resources, and treat everything else as if it’s outside the perimeter So in fact, it’s about a more secure perimeter than before And so the right solution you really want in this world of applications being everywhere, users being of various types, and users being everywhere is that you want to solve the problem at its very core And the problem at the very core is you have an information resource– for example, you a finance system– you want to get the right person, perhaps someone in your finance group, to access it in the right context So the context would be how sure am I that it’s that right finance person Are they being phished? Has their device got malware? Are they in my country? Let’s say it’s a country rule saying you can only access it from inside the country In that context, you should be able to make a decision for that application way up the stack, not at, like, opening ports and firewalls and things along those– and that’s what we really want And this is what, basically, Zero Trust access is about And in Google, we built a solution for this driven by the fact that we’re constantly under attack for our internal employees over many years And it’s called a Beyondcorp product And in fact there are a bunch of papers You should go and take a look at them Just Google Beyondcorp And we learned from this, and we have productized some of these So when you go through the same journey, hopefully you can get a much faster start Because some of our lessons are just built into, like, a package service for you So stepping back, even before we talk about Google’s products, if you want this notion of Zero Trust access, what are the components that you actually need? And you should think of it as a comprehensive solution for applications you might own, like web applications They could be on prem, on any cloud, there could be VMs you need to SSH to, SaaS applications which you are purchasing And your API as an infrastructure– you should be able to say, for example, this production API only from a well-managed laptop, only by my net admin group, and with strong second factors You should be able to say that, and something should make it so So what do you need? You need a notion of who the user is

You need user trust So the sense of identity, understanding of a user security and behavior You need device trust You need to understand what device are they’re using Is it patched, what version of the OS, where are they, and things along those lines Then the overall context– where is the access coming from? Are they in a restricted country right now when they’re making the access? All of this feeds into a rule decision that you make So for a decision like I said before, this application can be accessed– we have finance employees in France, let’s say That rules engine is where the rules are, and makes an enforcement decision, which is an enforcement point, which is typically a proxy And so a proxy meaning it’s what seems to be the application, to the end user, but it’s making a decision before allowing the access to go back to the real application So we have solution components for all of this in Google Cloud So we have this very powerful identity system called Cloud Identity which can federate to your SSO system You might have Okta, you might have Active Directory Or if you would like, it can also act as a primary identity system But it can understand what group your users are in It can even enforce secondary second factor So you can say things like, I know my primary second factor happened in my IDP, but when they come to do this particular API, or this particular application, I want them to have, like, a unphisable second factor with a security key, which I’ll talk about a little bit later So you can do things like that We have Endpoint Verification We can monitor, in a lightweight way, device status And which you can correlate with deeper monitoring systems Like you might have CrowdStrike or Symantec But we can get you the basic endpoint on your device in a very lightweight, self-installed fashion Obviously a proxy understands the context– what time of the day is it, where are you coming from So you can write rules like, “only from Germany,” by just choosing Germany in the dropdown And we have these proxies You see this cloud IAP, cloud IM– let’s not worry about all the alphabet soup there But basically the point is if you use a GCP API, which is IAS, you can write the rules of the context of things I said If use G Suite, for example, using Google Drive, you can say, “Google Drive only from a well-managed machine” if you like Or if you’re using any of your web applications or SSH– so let’s focus on web applications Probably many of you have them It doesn’t matter where they’re running They could be running on prem, they could be running on AWS, on Azure, maybe on GCP We can basically act as the front end, which gives you what we call context-aware access And the context is like the holistic notion of all the stuff I talked about– who you are, device, and things along those lines So once again, looking at the picture on the right, the solution works for our GCP APIs today, for G Suite today, and for any web application that you have, and for SSH right now And basically, having said all this, let’s see what it really feels like And for that, I’m going to hand over to Gagan, and ask him to show us GAGAN ARORA: Good afternoon, everyone My name is Gagan Arora, and I’m a product manager in Google Cloud Over the next few minutes, I’m going to walk you through how you can set context-aware access in your organization today I know most of you are already using it, and some who have played with it Most of it has gone to GA now So I would really encourage you to go back and deploy some of these rules I’m going to go through three primary use cases, the first one being context-aware access for G Suite, how you can configure it and then manage it in your admin console The second one is around, if you want to deploy a device policy for context-aware access, how would you get started? Are there things that need to be deployed on the endpoint, and how would you go about doing it? And number three is if you want to deploy context-aware access for your own applications, not just the G Suite application So I’ll walk you through all these three use cases over the next few minutes So the first use case that I mentioned is context-aware access for G Suite And this has been in beta for a few months now, and many of you has already tried it out So the good news it’s now in GA So if you were waiting for the product to go GA, please go back and try it out again

One of the most common use cases that we have seen across many, many customers with context-aware access for G Suite is they have a lot of sensitive data in their Drive and Docs And they’re looking to make sure that any user who’s trying to access that data is coming from a device that has appropriate security on it So let’s see how you will set that configuration and a rule in your familiar admin console So in your admin console, if you go to your dashboard, with Security panel, now you will see a new card called Context Aware Access Once you get inside, you’ll see three different sections Number one, you need to define access levels, which is just a bunch of conditions that will define the security posture of your organization It could be things like Device Policy, IP policy, and things like that The second one is you will assign that to a set of users and a set of applications And the last one is you will define what your end users will see if they do not comply with the policy that you have applied for them So let’s look at how you will define the access level first So in this case, you can go and select your IP subnet And this is a very popular use case where you can define the IP boundaries on where users can come from It could be your corporate network, or it could be a contractor’s corporate network, and things like that You could also define that somebody must come from a specific country Now, this could be based on your internal company policy, compliance, or regulation, or anything, so on and so forth The last one I wanted to show you is the Device Policy And here you can start to enforce things like the device must be encrypted, it must have password on, and the Mac OS version is, say, higher than 10.14.5 You can also enforce that the device must be company-owned or it is approved by admin before it’s accessing your corporate data The next one is applying that access level And for this demo, I chose analyst as my OU that I’m applying it to, and Drive as my application, because that’s the use case we are trying to solve Once you have defined this policy, the next thing I will do is go and provide a message that the end users will see when they get denied access because of the policy that I, as an admin, is applying So this could be your internal internet address, or it could be your admin address that they can contact So let’s see Dan, who’s an end user in the analyst organization, he’s trying to access Drive and Docs from a Mac which has a password on It’s encrypted And his OS version is 10.14.6 So everything checks out He gets access to his Drive, and can access the documents Now let’s say our vulnerability has [INAUDIBLE] And you want to make sure all Mac devices that are accessing your drive now have at least 10.14.8, which is the latest patch version In this case, all you have to do is go back to your access level, update it to 10.14.8, and it’s saved And this will trickle down to wherever this access level was being used for the context-aware access policy So Dan is still logged in He’s working through his session And anything he clicks next, he will be denied access, and will see the message that you have configured for Dan So as you can see, it’s a fairly small, few-minutes process You can pick a set of users, some applications that users are already using, and start configuring these rules today One of the most common questions that we get asked is you’re collecting all these device attributes and applying context-aware access policy for it, is there something that needs to be installed on our machines? The answer is yes You need to have an Endpoint Verification, which is also a Google product and a Chrome plugin that needs to be installed on these devices The good news is you can download it from the Chrome Web Store and push it to your end users, or you can ask the end users to download and install it themselves Once installed, you will see an icon on your browser that says the endpoint is installed and everything is working fine And from that point on, you can start to look at the device inventory of that device You can go back to your Admin console, go into your Devices panel And when you go to the Endpoint Verification section, now you will see all the devices that have endpoint verification installed in it And this gives you the capability, even if you are not using context-aware access, to get a sense of who is exactly using the machine that was handed out to a user It gives you various other parameters, like password, what’s the status of the encryption, and so on and so forth One new thing that we just introduced

is fundamental desktop management And this allows you to see which desktop devices are accessing your G Suite data, and even the devices that do not have endpoint verification on And this is very, very useful for you to actually see who’s accessing my G Suite data And then you can use that information to send them an email letting them know of the company policy Or in some cases, you can tell them, go and download this endpoint verification; without that, you might not get access Now, the things that we talked about– I just talked about G Suite so far The exact same context-aware access works for your own applications as well It’s the same platform as I mentioned, same underlying infrastructure that we have built that you can use against different enforcement points in your organization So let’s look at a quick use case on your own applications So imagine it’s a made-up company, Zatkix.com, and they have an HR application that they want to expose to the contractors And the HR department wants to make sure that the contractors are only accessing this application when they’re in their office, and they’re using their own company devices And this is primarily needed because they want contractors to fill out some data in the application, and they want to give access And imagine that the contractor is actually not even in the same country It could be in some other country as well So in the past, the solutions that were available to us are really not practical for this use case So you could start to think of I can use VPN, but again, you don’t want to do that with contractors in most cases Or you can fly them in, which again is not a very practical solution IAP, along with context-aware access, solves this use case beautifully And it can also solve your security department concerns So for Zatkix case, the security department wants to make sure that the user– the contractor– is actually coming in with strong authentication And they must be coming in from the corporate location So let’s see how this will be done for a contractor who is sitting in a different location So Kelly is in Acme.com, which is a contractor corporate location And she is trying to access this HR application that we have provided for her She has asked for login, password, and also for the strong authentication, the security key Now, Kelly does not– like, we don’t have to send any key to her She can purchase their own key, and then register that key for the second-factor authentication Now, let’s say Kelly does not know what the company policy was So she walks over to a nearby Starbucks, and she tries to connect to the same application from Starbucks So she is now connected to Starbucks And she’s going to go through exact same steps, for exact same application, from exact same laptop So once Kelly enters her username and password, she again is prompted for a second factor She provides the security key that she registered And in this case, she will get denied access because your company policy says that Kelly cannot log in from anywhere outside her own company location So as you saw, the page that the end user sees is exactly the same that you saw for G Suite And it is again primarily because the whole infrastructure that is used for building context-aware access as a platform is exactly the same for G Suite and for GCP With that, I would like to invite Adam on stage, who’s going to talk about how Deliveroo has enabled context-aware access in their organization today Thank you ADAM THOMPSON: Cool Thanks, Gagan So I’m the information security officer at Deliveroo And I’m hoping this session will encourage you to adopt context-aware access, and highlight some of the benefits to it So first of all, I’m going to set the scene I’m going to talk a bit about why context-aware access for Deliveroo specifically, talk about our implementation journey, and what worked and what didn’t, and also what we’re looking at in the future So first of all, who is Deliveroo? Deliveroo is a British tech startup And it was founded by Will Shu and Greg Orlowski six years ago now And we’re a multi-sided business So we engage with restaurants– quite a few of them, actually– all the riders that we partner with, and consumers And we operate in 13 different markets across the world And each one has a presence from an office point of view

So we have employees accessing our data from all across the world A bit about Deliveroo’s architecture– our products are primarily, actually, in AWS And we have some minor usage of GCP for some non-critical applications as well For collaboration, we mainly use G Suite And for device management, which I’ll reference again later, we use Jamf for our Mac estate, Intune for our Windows estate, and Google for Chrome OS So what does Deliveroo classify as a secure device? We want to know the serial number, and we want to know the owner of that device as well We want to make sure that there’s a screen lock enabled on it We want to say you must have a password of a certain complexity, and that the device is actually encrypted, so that if there’s any data on it, that it’s secure We also want to know that the patch management of it is actually up to date, and they’ve been rolled out, and nobody’s actually clicking that button to ignore the update We also want to make sure that we’ve got some endpoint detection and response on the device so that if something goes wrong we’re aware of it and we can act We want to make sure that it’s a company-owned device and not a personal laptop Because that’s not something that Deliveroo permits right now It’s something that we’re going to look at in the future But we do use things like Google Device Policy for mobiles so people can actually bring their own mobile device along And Chrome OS is being issued as the preferred device across the company at the moment– mainly to non-engineers, though– just because it’s inherently more secure with things like verified boot enabled, and the fact that you don’t need endpoint detection and response on it, and the configuration management software that you need to operate it And both of those have a cost, too, as well So context-aware access was compelling to Deliveroo for four main reasons One of them, we set out a key metric that we want to know 100% of the devices that are connecting to our services And if you think about it, right now, if someone tried to use their personal laptop to access G Suite services, would you know about it? And it’s a perfectly good question to ask, especially from the security point of view And we have a range of partners that Deliveroo work with, especially around the customer-support side of things And they work in a specific location in a specific country And context-aware access provides you with the ability to actually restrict it to a specific IP address so that when those partners go home they can’t access it from their home devices, and they’re actually on their secure laptops from the company that they’re working for And Deliveroo doesn’t use a VPN like a lot of traditional companies do We’re really, fully SaaS, and everything’s in the cloud We don’t have any on prem, apart from maybe printers And we can always can do with that extra context as well So Chrome OS is also context-aware access-enabled by default as well, which encouraged us to up our game on Windows and Mac So when it came to getting started, there’s two key pieces– the Endpoint Verification Chrome extension and the native helper And I’ll go through a bit about how we went through rolling this out So initially we rolled out the native helper agent behind the scenes using Jamf and Intune so that users didn’t know that it was being there, and later on, it doesn’t require an additional click to download and install And then we went on and we used the Chrome browser management to force-install the extension to all of our managed devices as well And this really allowed people to have a smooth installation for all signed-in Chrome users, but didn’t help us for the devices that were not signed into Chrome, and, say, using Firefox or Safari So then, as well, at that point, it’s always good to enforce Endpoint Verification for all new employees so you’re not chasing your own tail, and you’re not trying to remediate something that could have been solved when they’re coming on board And from the cultural aspect, they’re used to it immediately And it’s not like you’re enforcing something new on them So then we were at the point where we were requiring users to click on the extension and click Agree So, notoriously, users don’t always do these things And one of the key things that we had to do was start looking at enforcement to make sure that we had the full enrollment that we wanted So we then used an access policy that required endpoint verification present to allow access to G Suite But we didn’t actually block all of our services We only blocked Calendar and Drive Because they need to get in contact with us somehow

So we left them with email And on top of that, we rolled out gradually over a certain period of time So we didn’t impact every region at once, and then have a load of support come in if there was any issues So at that point, we were able to verify our devices against the inventory that we had And we were able to enforce our policy if we found any devices which are being used outside of our policy, which is that you’re not allowed to use your personal device for work purposes– I mean laptop And then we had to issue a few new devices for those devices that weren’t supported And I’ll come onto that in a second So what really worked as part of the context-aware access rollout, we really got instant visibility And we were able to act on the numbers that were provided to us For example, how many devices in what region had endpoint verification, and which ones didn’t And that allowed us to actually organize support So if we had to do out-of-hours for our offices in Australia, we could actually be online Because actually our IT support is 9:00 to 6:00, say, in the UK So we would have to provide that out-of-hours support So having those numbers is really critical to understand how many people might actually being in touch So if you said that 20% of the users had Endpoint Verification installed, but 80% didn’t, you’d actually know that there may be a lot of support that comes through So to help resolve all of that support issue, on top of that, we made sure that we had a lot of comms that went out, and that went through all mediums across our company And that was internal social media, emails on specific regional rollouts And actually we created a dedicated Slack channel just for the purpose of endpoint verification, to make sure that people could actually have a dedicated place to come and reach us at And then, at the same time, we would always try and provide people with the ability to self-resolve these issues So by providing them a playbook that tells them, just make sure that you’ve clicked Enable, and accept the privacy policy from Endpoint Verification actually helped us resolve a lot of the issues, as well as doing things like ensuring that sync is on between Chrome and your G Suite And then something important as well was actually to make sure that you have a process defined for handling exceptions So for instance, if there is an unsupported device the context-aware access or the native helper does not support, then you need to be able to put someone in a different OU to have that exception in place so that they can still do their day-to-day job whilst you go about resolving that through the normal IT routes So I want to go into a bit of detail about what didn’t work, and what could have been a bit better for us And I think some things are summarized on this slide And really it’s around the fact that a few things were blocked by context-aware access And this is important to consider in the impact to your users So enabling context-aware access for Google Docs blocked access over mobile web because it doesn’t provide the context back And so this worked for things like the mobile apps for Sheets, for Docs You can so access all the core systems that you need to access But it caused some friction for people who wanted to use Google Forms, which is still part of Google Docs, and doesn’t have a dedicated app So to get around this, we also did some work to enable people to still use Forms, but actually using Google App Maker to create a custom form ourselves, to get around that and actually enable it So it’s all these things that really help you push it through and create less friction for your users, while still keeping security at the forefront So only Chrome is supported from Endpoint-Verification perspective at the moment And that means that people can’t use browsers So you should actually consider the people using things like Firefox or Safari, and what work needs they may have for doing that Most of them are not related to G Suite But there may be some related to specific applications that you have So consider that when you want to put them behind context-aware access, including .iap So we had some old devices in our fleet as well So there were some issues around support for Windows 7 and 8 These were actually good to highlight, and actually helped us refresh those devices and bring them in line with our expectation from an inventory point of view And there was limited logging into denied-access events, which kind of prevented us from debugging and looking at what the problems were that people were facing And then we had a piece where we were shipping Chromebooks directly to our remote offices in different regions And this meant that people missed that enrollment step So instead of going through the Enterprise login, they were logging in through their normal domain And that meant that we weren’t getting a serial number back from our devices And it meant that we had to come up with something inventive

to try and resolve this issue In a more automated fashion, and look with enablement in our heart So we came up with an extension that would pop up based on the criteria of the device So if we didn’t get the serial number back, we would trigger an extension to be installed on their Chromebook, and pop up, ask them for the serial number, to provide us that contact so we can check against our own inventory to make sure it is actually a company laptop, and then encourage them to go through the process and troubleshoot the problem themselves So it would provide them the playbook to resolve the issue via email And if they then didn’t do that, we could get in touch But it resolved a lot of the issues for us without having to be involved with this And I hope that we’re going to be able to open-source this piece in the future as well to please check out our engineering blog in the next few weeks So, future requests from our side is– a few of them are already done, which is great So we wanted some more audit logging capabilities around the access-denied events, information around the users, and the policies that we were enforcing and what was not working So Linux support– we still have a range of engineers that use Linux So we wanted to bring context-aware access to them as well Custom messaging– so you would’ve seen, on Gagan’s demo earlier, around the custom messaging that was provided That wasn’t there So we couldn’t tell them to actually go to this Slack channel So we had to rely on the other comms even more to get the right engagement from our users And then we really do want some more external troubleshooting information for administrators Like, hey, why is this person getting rejected? Is it because their device is not encrypted? Is it because their OS version is out of date? It all helps us in debugging and providing better experiences to our users And some more APIs from the context-aware side would also be helpful If we want to block a bulk load of devices, we want to be able to do it through an API and programmatically, rather than through hundreds of clicks through the UI So that would be super helpful We’d like Firefox support for other users in the business so that they can actually use another preferred browser Forms on mobile would be great And also something that actually would be super helpful for Deliveroo is actually having context-aware access for SaaS-based apps So if you think about Workday, and Salesforce, Twilio, anything that may be through SAML or OAuth, if we can apply context-aware at that point, it would really close the gap on people potentially accessing those systems outside of their work devices So what’s next for Deliveroo? We want to refine the policies that we’re implementing a bit more We can do things like implement a minimum OS version, and make sure that we’re actually on top of the patch management side of things, and bring it in line with context-aware access so– like Gagan said– if a vulnerability does come out, we can actually protect our data that little bit more So context-aware access for our internal apps is also something that we really want to pursue as well So we’re going to pilot Identity-Aware Proxy on a grab-and-go web application that we developed, and then evaluate it for a wider rollout across the organization, and understand the potential impacts on that and our infrastructure Because everything is in AWS So putting Google in front of it would be an interesting conversation And then eventually we want to enable our users to use their own devices And this goes for contractors or employees We don’t want to force contractors who are working in a country supporting some sales team to use our own laptops and send one to them, because then we’ve got to maintain that cycle of the IT side So we want to be able to enable BYOD and actually restricting access based on the context of the device and the person using it will be super useful So that’s it from my side on Deliveroo And I just wanted to give some props to the IT team, especially [INAUDIBLE],, who’s in the audience, for leading the implementation of this And I encourage you to check our engineering blog and careers And thanks And I’ll hand over back to Sam [APPLAUSE] SAM SRINIVAS: Thank you, Adam So I hope we left you with a sense of what Zero Trust access is, what drives it, and a concrete feeling for what you will get if you implement it with our tools with the demos Gagan showed And probably the highlight of what

we talked– about Adam’s presentation about what a real-world rollout looks like And having said that, let’s talk about, if you want to get started, what might be a way to go So this is a new form of access But the way to think about it is like evolution and not revolution You’re not saying, rip out the VPN, change everything, ditch the perimeter– nothing like that You can overlay the solution where it solves some kind of pressing initial use case for you So you can pick some particular use case Obviously a driving use case for Adam and the Deliveroo team was basically the G Suite use case You can try that, and you can see how carefully they staged it There was no real disruption You can start with a small group, and so on Another use case which happens is that you have an internal application which you want some external entity to have access to in a very convenient way which is not possible today So sort of taking the internet application, externalizing it And you can do that pretty much sort of– in quotes– “instantaneously,” with, like, putting it behind identity-aware proxy So if you do that– I’ll just take a example, let’s say, some contractors need to access an application on the outside, put identify-aware proxy, first try it out with a small group of your own users to see how it feels, what the latencies are, what questions come up in your team, have very simple access rules initially, maybe just rules which are based on user group, do not have even device status as yet So only this team can access it So you can get a feel for how the rules engine works And run a pilot Basically maybe get a couple other contractors to use it Find real-world issues from, when they’re far away, what happens And then you can layer on additional security So for example, you can have IP rules, which you saw, device rules, which you saw Or you can layer on MFA So one thing which I referred to in the beginning of the talk was this option that you have with login system, which is called security key, based on these standards with FIDO It’s really like an open-standards, anonymous smartcard And it basically gives you a login which is inherently designed to not be phishable So it’s a very high grade of security relative to any other MFA you can use today Because just by the nature of things– anything, a push notification, ODP– they can be phished if it really matters So anyway, you can try an MFA Maybe you have a production application No one should ever see this dashboard except my NetOps people But I want them to see it from anywhere Because in a crisis, I never know where Jim or Sally might be But you can make it accessible to Jim and Sally from their phone, but they have to use a security key, things like that And after the initial pilot, you can grow into production, you can bring more applications in And in the Google experience, we did essentially this And we go to thousands of applications And in the end, we keep shrinking the use case for all the forms of access and employee access to our VPN to the point where we have a vanishingly small use case There will always be something that is on HVAC system, which basically is only in use of Windows 95 client But you can contain those to a very small number of people who can use it And so at this point, when we live in Google– we live all web, in fact, very much like Deliveroo does– basically there’s no difference in the intranet and internet for us And once again I’ll point out that it’s not that we got rid of the perimeter We made the perimeter much stronger We shrank it to be just around our application servers, and essentially cut off all access except at the application level, and we know who’s doing what So with that, we have some time for questions And if I could invite Adam and Gagan to come and join me on the stage Yeah, please go ahead AUDIENCE: What are your plans for Android support? SAM SRINIVAS: Android support? Yeah So the question is, what are your plans for Android support? So right now, a browser-based application, it will work through, obviously, any browser So we have an example of a use case where a major retailer wanted access to a line of business application for their store stuff and roaming the store floors, and from Android devices And that works through a browser And it only works within the stores That’s an example However, you’re probably talking about applications

And we have, essentially, a context-aware access All this subsumes device management capability that we have And so today, at least for our first-party applications, the use case which, for example, Adam showed on the computer, which is, unless this is an in-reasonable-shape laptop, don’t allow Gmail, you can do the same thing in Android, where you can basically say, for example, unless this has a screen lock, and unless it’s not jailbroken, unless it’s locked, don’t allow Gmail And that’s something you can do today So we essentially have an app extension for these And it also works in iOS Yeah, please go ahead AUDIENCE: Hi Thanks for showing the demo One thing I’m actually quite interested in is you’ve got the context-aware manager and the proxy on the edge of the system Could we deploy this solution in a VPC search perimeter for entire applications instead? SAM SRINIVAS: When you say that, do you mean it’s inside your perimeter of your– inside, within your VAN? Is that what you mean? Within you’re own network? AUDIENCE: Yeah, so I’ll give you a use case here if I may We’ve got an application which is a server base for a machine-based application– or credential apologies– making an internal call to a target system I’d like to apply policy which says that this resource, be it BigQuery, a GCS bucket, for example, may only be accessed by this object at this time or location, or whatever context I wish to program in the device, which then protects me from insider risk SAM SRINIVAS: Yeah, so that’s essentially API call to GCS, right? Is that the– AUDIENCE: Yeah, that could be one It could be another application I’m hosting SAM SRINIVAS: You’re substantially going to apply these In fact, you can– the short answer There’s a thing called VPC service control I know we have a little bit of alphabet soup But that’s what he should look for in the documentation AUDIENCE: Yeah, that’s the actual problem Because it doesn’t apply to serverless functions SAM SRINIVAS: I’m sorry? AUDIENCE: It doesn’t apply for your serverless functions SAM SRINIVAS: Serverless functions as yet AUDIENCE: Yeah So as a result, can I use this to broker the connection? SAM SRINIVAS: You know, I’ll connect you to Grant who is here in the front, and we should have a deeper conversation about this In fact, he is the lead architect of VPC SC And anyone else interested in the topic, please stay back to talk to Grant AUDIENCE: Thanks very much A question for the Google guys– could you talk a bit more about wider browser compatibility So I noted Adam had, on his slides, Firefox compatibility That’s hopefully on a roadmap at some point And also, is the support for the enrollment using the Chrome Web Store add-in– is that the Chrome only, or is that for Chromium-based browsers? I.e., could we, for instance, expect Microsoft Edge-based Chromium to, out of the box, use the same add-in? SAM SRINIVAS: Should I take that, Gagan? GAGAN ARORA: Yeah, so currently it’s based on the Chrome browser So the plugin works on the Chrome browser only But yeah, we’re looking at other pieces as well SAM SRINIVAS: Yeah, in fact, add a little bit more color to that The reason why it’s Chrome-only is because essentially what we need to do is, in the context of being signed in, we need to report session data Basically we want to say, Sally is signed in on this Macintosh And in the context of session, please attach information to this session saying it’s a Macintosh, and it’s got a screen lock And it so happens that Chrome is integrated into our identity system She you’re signed into Chrome And we have this mechanism to decorate the session with more information We don’t have that mechanism at this point in other browsers But it’s conceivable And we fully recognize– in fact, despite creating Chrome, we believe in a multi-browser world So it is very high on our radar as to what to do And as far as whether this is Chromium or Chrome, my guess is it’s Chrome-only, but we can get you the exact answer AUDIENCE: Thanks for your presentation A question I have around the demonstration on the coffee shop access– so when the user actually had that failed message, there wasn’t really any feedback for the end user to actually understand why they’d failed So it might be actually useful to actually get some kind of thing– you’re accessing from a location that hasn’t been authorized, or that kind of thing Is there a mechanism where the user can get feedback? Because otherwise you’re going to get lots of support requests SAM SRINIVAS: It’s a good question But Gagan, why don’t you take– GAGAN ARORA: Yeah, so I think what Adam mentioned, when they rolled out, there was no capability to specify these custom messages to your end users When we went GA with the product, we actually introduced this capability So you can actually specify what you want

to convey to your end users And again, it depends on the companies You may want to specify and tell them exactly what your company policy is But for various reasons, you might choose to not disclose every information, every policy that you have for your company So the inbuilt capability right now is you can actually specify that, yes, if you want to get more detailed steps on how users should do it, you can point them to your internet site or something else Or if you want to just specify, contact Bob at admin.com or whatever it is, you can specify that and they can reach out you So it really depends up to you how much information you want to share about your policies with your end users And this capability you can apply on OU-by-OU basis So maybe your engineering department, you want to share more steps that they can take on their own, versus some other department where you actually just want them to contact you SAM SRINIVAS: Adam, what was your experience with this in real life? ADAM THOMPSON: I think it was an interesting one Because we didn’t actually have that message But it actually wasn’t a stopper or a blocker It didn’t really create that much friction because of the amount of comms that we did, and that those comms were successful, really People knew to come to the Slack channel, or they knew someone that would know to come there And communication to, say, office managers or key people within the company will really help that process as well So I don’t think that– although it’s nice to have that custom message, because now we say, go to that Slack channel if you do have issues But it’s really not strictly necessary for a successful rollout SAM SRINIVAS: Yeah But having said that, we have gotten this once it’s on our roadmap to improve things But one thing which we– and I don’t know whether you agree with this, Adam– even more feedback we got was when things get denied, give tools to the admin to understand what happened And that’s something we’re working actively on So at least when you’re watching the green screen on the other side, you’ll say, hey, lots of people in Germany, and they all seem to have gone for a conference, and nobody gets access You can see that and whatever ADAM THOMPSON: Yeah Even something like being able to measure the number of laptops that would be affected by a policy would be awesome AUDIENCE: Thank you very much I’m just trying to find out the issues you found when you were implementing it with Deliveroo Were you able to monitor every single movement? And you said you couldn’t do some things, and some things were able to achieve I’m very interested in seeing how user specification played out with implementation ADAM THOMPSON: Could you be a bit more specific around the monitoring side? AUDIENCE: Yeah Assuming that you had an app that could overlay Google Maps, in which case, you can locate every single movement of your men in the field ADAM THOMPSON: So we didn’t get the context of, say, someone’s device location specifically I mean, we probably could have through other means of other management But we mainly used the context that Endpoint Verification was providing us, so information around whether there was a serial number, whether it was encrypted, and using that information tied with all of our other device management software to create a bigger profile of what created more value for us in the sense of communication or remediation to issues So if we knew a specific OS was problematic, we could then go and target those users really quickly But there wasn’t anything specific around security monitoring of individual behavior or anything like that that we were actually looking at GAGAN ARORA: Yeah, I think, to add to that, the things that we showed on Endpoint Verification are the things that you actually get to see from the device– so whether the encryption is on, whether password is on, what is the OS version, and things like that And the second thing is the IP of the user, which anyway gets sent to the browser for the connection So those are the two things that get sent Yes ADAM THOMPSON: I think we have time for one more AUDIENCE: Thank you for the presentation Are there any parts of those– like the policies that have kind of a deny function? So instead of saying, oh, you must have this device profile, you must have this OS, you must have whatever feature, well, actually you can have all of these features, but you cannot have this particular version of an OS? SAM SRINIVAS: Not yet One thing I’ll say is that the rule system is essentially based on an IM system below AUDIENCE: [INAUDIBLE] SAM SRINIVAS: Yeah AUDIENCE: [INAUDIBLE] SAM SRINIVAS: Occurring tonight? AUDIENCE: Yeah GAGAN ARORA: Yeah, yeah, so I think when we were setting up that access level, I only showed the version where you are actually allowing based on certain conditions There is an equal [INAUDIBLE] not around it, which is, block if these conditions are met

So you can actually apply whether it’s allowed or not allowed based on any of the conditions that we described SAM SRINIVAS: I was interpreting your question in a slightly different context of having a deny semantics end rules But what Gagan said is the relevant answer GAGAN ARORA: I think we’re almost out of time But we’ll take one more, maybe, and then we can catch up at the back of the stage AUDIENCE: Sorry Just want to ask another question, actually So from a delivery perspective, given that the technology was relatively immature compared to competitors out there in the market space, what made you choose using this tool versus some other context-aware access competitor? And how much support did it get from Google overall during implementation? ADAM THOMPSON: I’ll answer the second part first And really there wasn’t actually much support required from Google But what they provided us worked in the way that they actually described I think the reason why we chose context-aware access is because it’s built into the Google ecosystem And we’re invested in that, right? We use G Suite as our primary Collaboration Suite And I think that’s one of the main reasons why we pushed ahead so swiftly with context-aware access, because it ticked two of the boxes for us And it was fully integrated And there’s no compatibility issues, because it is all Google GAGAN ARORA: All right I think we are out of time But we are happy to stay around for another few minutes If anybody has questions, please feel free to come and get us [MUSIC PLAYING]