[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]
