GREG DEMICHILLIE: Our second speaker on our second topic
is about security.
Niels Provos is a distinguished engineer
at Google focused on security and privacy.
Now for context, there are only about 50
distinguished engineers inside all of Google.
Now, and according to his Wikipedia page,
in his spare time he's turned steel into swords.
You know, and security is different
than many other features.
It's an opportunity for us to work with you
to create the best possible security environment for you,
your customers.
And with GCP, we have a great opportunity
to put more and more of the tools
that we use to manage our security into your hands,
so that you can manage your security as well.
So with that I'm really delighted
and honored to bring up on stage Niels Provos,
distinguished engineer from Google.
Neil.
[MUSIC PLAYING]
NIELS PROVOS: Thank you for the introduction, Greg.
Good morning, everybody.
As Greg said, I am a distinguished engineer
at Google.
I am responsible for the security and privacy
engineering teams.
Today, I would like to pull back the covers a little bit
and share with you a glimpse on how we pervasively
secure you, your data, your customer's
data, and your applications when you run on top
of Google's cloud platform.
However, let me set the stage a little bit first.
At the recent Enigma conference in San Francisco, Rob Joyce,
the head of NSA's Tailored Access Operations
made the following statements on how
advanced adversaries managed to break into your systems
and networks.
Now I understand that most of you
would like to spend your time and focus
on building a great product and great new features
for your customers.
However, your adversaries, they focus their time and energy
on finding weak spots in your systems that they can exploit.
Fortunately, at Google I lead the team
of experts, who build systems and processes, specifically
designed to thwart adversaries.
We do this by anticipating them, preventing them,
detecting them, disrupting them, and containing them.
And we will work with you to make sure that we
can meet your requirements.
And that you can leverage our security capabilities
on top of the platform.
So now I would like to give you a little bit more insight
into how we think about security at Google,
and how we have created a secure infrastructure for ourselves.
Google security and privacy team consists
of over 500 people, who continuously
work to protect our infrastructure,
and you when you're running on top of GCP.
Due to our scale, we end up seeing
all kinds of bad behavior across the internet-- phishing
emails, malware websites, network attacks.
And we also see all kinds of adversaries,
ranging from all levels of sophistication.
Not just script kiddies and cybercriminals, but also
nation state actors.
Now at Google, we are not pursuing a hard shell
or perimeter model.
Instead we are really focused on pervasive defense and death.
This is similar to the immune system analogy
that Urs mentioned yesterday.
There are two key principles running pervasively
to our approach to security, and they
are trust and transparency.
That means that we design for trust throughout our stack.
And we build in the transparency,
so that you can verify for yourself.
And in fact, this talk is one of our steps in giving
you more transparency.
Now I'll be talking about Google's infrastructure.
In the first part of the talk-- how
we think about security there.
And then the second part of the talk, I
will explain how that applies to you when you run on top of GCP.
In order to facilitate this discussion,
we have split our stack into eight different layers.
And I'll be walking from the bottom
up, starting with the hardware, to the boot process,
all the way up to deployment, operations, and usage.
At the hardware layer, we are fortunate enough
that we operate at such a skill that we
can build our own proprietary secure systems.
That means that we have purpose-built hardware
for computing, storage networking, all the way
through the full data centers, as you just
heard Joe talk about.
Our ability to design and deploy custom hardware
means that we can maintain provenance and establish trust
at the hardware level.
Now on top of this trusted hardware,
it's important that we can also boot in a trusted way.
And to accomplish that, we have complied code signing that
allows us to verify the BIOS, the bootloader, and the kernel.
And that means that only the intended software can
run on Google's infrastructure.
So now that we know that our machines have booted
in the known good state, it's also important
that all of our jobs communicate in an authenticated and
authorized fashion.
To accomplish that, we have built
a cryptographic key distribution system
called LoA, that allows us to establish
cryptographic identities for all jobs that
run on our infrastructure.
We know and audit the binaries that run,
so we can establish trust, not only at the operating system,
but also for the apps that are running on it.
Now we have heard a lot about virtual machines.
And one of the properties we really need there
is secure isolation.
At Google, we use KVM as our hypervisor technology,
and we have significantly invested
to harden its security.
That means that our security teams
have found 15 of the last 21 publicly known vulnerabilities
in KVM.
That means that we are the first to fix, and the first to patch.
But of course, we also contribute our findings
back to the community so that everybody
can benefit from a more secure KVM technology.
And we continue on working to make KVM even more secure.
To get a secure operating system image in our machines,
we have created a Google curated image
that we run throughout our production infrastructure.
This is very similar to the recommendation from the NSA
of having a secure baseline.
We have also deployed a service that
alerts us of vulnerabilities and third-party source code
to further protect our services.
Now, at the storage layer, it's really important
that all access to data is individually
authorized and echoed.
Before we write data to disk, we chunk it and spread it,
so that not all data ends up on the same server.
We also encrypt data and metadata individually.
And to protect these encryption keys,
we have built a system called keystore, that wraps them
by encrypting them further.
Our storage systems only store this rep key, never
the original cryptographic key that would be
required to decrypt the data.
And that means that all access to data
requires interaction with keystore,
which gives us logging and auditing capabilities.
Similar for data and motion, we encrypt it
when it travels between systems that we control.
We accomplish fine-grained control
over access with our internal IEM systems,
and they also give us logging and other capabilities.
So now at this point, we are running on trusted hardware.
We know that the boot process was trusted
and we trust our operating system.
And we also have provenance for hardware, boot, and OS.
We encrypt the data, or we know that all access
is authentic and authorized.
Now to secure our applications, we
are pursuing multiple layered approaches.
One of them is that we have built a binary on configuration
verification system.
That means that for all applications,
we know how they were built, we know how they were configured,
and we know how they were deployed.
And for each of these steps, we know
who was responsible for them.
To put additional security into our development process
we require that all code gets peer reviewed.
That means there's a second pair of eyes that looks at the code
before it's being committed, so that we
can find bugs and security problems very early on.
To help our teams create more secure systems,
we also require security of you before anything can launch.
That means that we can put security into our products
right at the design phase.
However, even with the best practices,
you still cannot prevent all security problems.
And so we have created a security scanning technology
that allows us to find many of the common mistakes--
cross-site scripting, mixed content, mixed pinning.
You know, more strange attacks such as Rosetta Flash.
And we have also used this as an example,
and where we can contribute back to the community,
we have made our Firing Range testbed open-source.
That is, if anybody else would like
to develop their own security technology-- scanning
technology, we already have a ready-made app
that they can test against.
So at this point, our applications are reviewed,
they have been tested, we believe
they don't have vulnerabilities, data is encrypted,
and access is authorized.
But now, it's time to expose these applications
to the dangerous web.
And there are multiple different ways
in which we secure our applications there.
First of all, on the network we protect the traffic with TLS.
To prevent man-in-the-middle attacks,
we have put certificate pinning into our Chrome browser,
so that we only trust the right certificates.
We have also deployed unphishable user identity
to our users with unphishable hardware second factors.
And to protect against network attacks,
we have built in DDoS protection.
Some of you might have heard recently
about Project Shield, where we announce that we're extending
this DDoS protection to news and human rights organizations, as
well as election monitoring sites.
[APPLAUSE]
Thank you.
[APPLAUSE]
At the operations level, we have built technology
that allows us to patch and monitor,
to incident response, forensics, threat analysis, and threat
intelligence.
And this is also another example,
where we have contributed back to the open-source
for making some of our forensic tools available,
such as GRR or recall for memory analytics.
Now, one of the sayings that we have is,
the first user who is going to be hitting your application
is likely going to be an app user.
So we give our developers the tools
to be able to do reputation checks on URLs and binaries.
We have automated analysis of traffic
to find botnets that might be engaging in spam.
And we also leverage our global view on botnets
to build threat intelligence on bad actors and current attack
vectors.
However, to reduce the overall attack surface that we face,
and that our users face on the internet, and that all of you
face, we created Project Zero in 2014.
It's a team dedicated to finding zero-day vulnerabilities
in critical internet software.
You may have heard about the Heartbleed bug in open SSL,
Urs mentioned that briefly yesterday.
Or about rowhammer, where just reading memory can
lead to remote code execution.
And most recently we announced a widespread security
vulnerability in GDIPC.
So that means that we have a team that
finds critical security problems that are very widely spread.
And we get the benefit of knowing about these first,
so we can fix our infrastructure,
but we can also work with the rest of the community
to make sure that we get the infrastructure fixed
in general.
As I mentioned in the previous slide,
writing secure software is difficult.
And Google has been one of the first companies
to create a vulnerability rewards program,
where we asked researchers across the world with helping
find security bugs on our products.
And just last year, we paid out over $2 million
to hundreds of researchers, who helped
us build more secure products.
So now, let's switch over to GCP.
I have just told you, and I hope you understand a little better
about the security capabilities that we
have built for ourselves.
You might wonder-- that's great, but how does that apply to us,
and when we run on GCP.
These security capabilities that I mentioned to you,
is what enables our Google Developers
to live the V3 cloud experience-- the next cloud
experience.
It means that they can focus on building amazing products,
and they do not have to be security experts.
Now we understand that many of you
are on a spectrum on how you develop and manage
your applications.
And all of you are going to be in different points
in your journey to this next version of cloud.
We understand that you may have to manage and segment
your network to create trust zones.
Or that you need more explicit control over the file
or of the network perimeter.
All of you need logging and auditing capabilities.
And we're really committed to help you meet your goals,
wherever you are on your journey to this next version
of the cloud.
And to accomplish that, we are increasingly
making more of these capabilities available to you.
And I'll be explaining to you a little bit,
how that is going to look like.
So I mentioned previously, we had eight layers,
in recognition of the need that many of you
need better control over the network.
We have introduced the network layer here.
So I mentioned to you what it is that we
do at the hardware level, what it
is that we do for our boot process,
and at the operating system level.
You are actually benefiting off all of these mechanisms
already, because GCP is built on top of this.
Many of you have ultra compliance requirements
and our infrastructure is regularly
audited by external auditors for SOC 2 and 3,
ISO 27001, PCI DSS 3.0, and for Google Compute Engine,
Google Cloud Storage, Cloud SQL, and BigQuery,
we are also covered under the HIPAA BAA.
That means that you can build on top of an infrastructure
foundation that is regularly audited and certified.
For cloud, at the storage level, all data
is already encrypted by default. To give you
even greater control on how data is being stored at rest,
we have made customer supplied encryption keys
available to you.
And we also give you audit logging capabilities.
In the future, we plan on giving you even more control
with a key management system, that
allows you to manage your own keys-- generate them,
rotate them, suspend, resume them, delete them, or manage
the import and export of secrets.
Yesterday, you have heard about our IM system,
that we have not made available to you,
which gives you explicit role-based access control.
And we will give you additional capabilities
later on in the year.
Now at the network layer, many of you
require explicit control.
In fact, today there are already many ways
in which you can customize your network,
such as with isolated IP groups, private IP addresses, VPNs,
or inbound firewalls.
We are working on extending and expanding
these features, including outbound firewalls.
When you run on Google App Engine,
you already can benefit from the security of scanning technology
that I mentioned to you earlier.
But with the cloud security scanner,
we are working on creating more scanners.
And on increasing the scanning capabilities,
so it can also use it on GCE and GKE.
We also plan to give you the ability to sign your binaries,
so you can verify and enforce what
gets to run as part of your infrastructure.
We are also thinking of giving you source code security
capabilities.
However, that requires that you first
store your source code with us.
So please check out the Google Cloud source repositories.
For protecting your developers and users,
we already give you the options of using
security keys, which give you this unphishable hardware
second factor.
Many of you at the moment, may be
relying on this sort of hard network parameter
that I've been talking about earlier.
We also plan on giving you detailed and sophisticated
identity and authorization tools.
That means that you can write access policy, not just
based on the user, but also on the machine and location.
You may have heard about the BeyondCorp model
yesterday, that sort of goes in that direction.
When you leverage Google's scale,
by using let's say the HTTPS load balancer,
you also benefit from built-in DDoS protection.
To protect your SSL and TLS certificates,
we have been working for years on something that is called
certificate transparency.
That essentially creates publicly
verifiable logs, that give you provenance and trust
for the certificates for your own domains.
For operations, you already benefit, essentially
from all the practices that we have
for the underlying infrastructure--
will be regularly patch and upgrade.
However, for your own projects, we
are looking into giving you an integrated view that gives you
an idea of the patch level of vulnerabilities
for your own deployments.
And we are also thinking of ways of adding some of our threat
intelligence into that for you.
You already can benefit from all that logging
and stack driver to give you a better idea
and detailed records of what's going
on with your infrastructure and your data.
In the future, we plan on giving a strong authors,
hardware second factor for logging into your projects.
But we are also investigating additional app use signals
that we might be able to make available to you
when you develop your application, such as URL
and binary reputation.
So these are just some of the security capabilities
that we will increasingly make available to you
to access and control.
You already have the option for us
to manage the security on the platform
if you use, for example Google App Engine.
But we also plan on giving you the ability
to leverage an increasing array of security features
that you can manage to your own requirements.
And to be clear, our goal here is
to provide you the control you need
on the trusted and transparent cloud.
So that you do not have to become security experts.
But can instead focus on innovation
and creating a great business.
Thank you very much.
[APPLAUSE]