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