CHRISTIAN TUEFFERS: Welcome to the session
"Master Security and Compliance in the Public Cloud."
My name is Christian Tueffers, and I'm
the senior Cloud architect with Deutsche Boerse AG.
I'm doing the session together with Grace Morrison
from Google Cloud.
In the beginning, I would like to give you a short overview
on Deutsche Boerse Group.
But we are a so-called market infrastructure provider,
and as such, technology is really in our DNA.
Our first fully-automated electronic trading system
was launched in the late '90s.
This one is operating on the lowest latency
networks and technology, and together with our core location
partners, we are operating one of the largest European
financial data centers.
All of our core business applications
are actually self-developed self-maintained,
and we do this with round about 2000 people in our IT.
Our core is really our trading and clearing applications.
As you can see, we use them not only for securities trading,
but in the end, for any kind of financial derivatives
trading, currency trading, but also trading
of commodities like energy.
In addition, Deutsche Boerse Group
is offering pre-trading services.
So we calculate return indexes like, for example,
the [INAUDIBLE] and the stocks.
We also operate ultra-low latency data
feeds for our customers.
The post-trading area is dealing with settlement and custody
services, and in addition, we offer value-added services,
like investment fund services or collateral management.
Everything of this is backed by our information technology.
As you can see, we are really a core element
with the European and global capital market,
and as such, we are under scrutiny of the highest
regulatory supervision--
not only by the German regulator,
but also by regulations in Luxembourg, Switzerland,
and the UK.
Deutsche Boerse Group is using public cloud
as one of the main technologies to drive our roadmap 2020.
Public cloud is fueling our foundations
for other technologies like, for example,
blockchain-based services.
We develop and run blockchain-based services
for digital assets or digital custody.
In addition, we leverage public cloud
for analyzing big data sets for of us or of our customers.
And we also make use of machine learning capabilities.
So you can see, public cloud is adding a lot of agility
into our mix, because with this, we can react dynamically
to changing business demands and we
can leverage new technologies to develop new solutions
for our customers.
But we use public cloud also to improve
the overall quality of our systems,
and this is achieved by standardization and automation,
and [INAUDIBLE] the additional possibilities
which public cloud offered to us.
As a good example, our core trading platform, called G7,
is spinning up every night hundreds
of test instances in order to conduct
some kind of random tests--
so-called "monkey tests."
And then, based upon the behavior of this,
we can improve the overall quality.
Of course, we use public cloud also
to reduce the operational cost by standardization
and automation.
We are implementing a so-called multi-cloud hybrid cloud
strategy.
As you can see on the lower right corner,
we are not leveraging only the Google Cloud platform.
In addition, we team up with all the hyperscalers
in the infrastructure as a service
and platform as a service area.
And also, for software as a service,
we work together with the market leaders.
The multi-cloud strategy is important to us
because it allows us to select really the best
service for each use case.
But in addition, it also prevents the vendor lock-in.
And this is something which is demanded by the regulators.
So whenever we move workloads into the public cloud,
we have to provide a so-called exit strategy.
The exit strategy could be that we either fall back
to on-premise, or that we move the workload
from one public cloud into the other public cloud.
In order to do so, we implemented a hybrid approach,
leveraging technologies like container and Kubernetes.
This allows us to dynamically shift workloads
between on-premise and to different cloud service
providers.
Now we know, of course, that this is not just
on a quick switch, but in the end,
it's sufficient that we can prove
that within a certain timeframe, we
can move workloads out of one cloud
and move it back to another one.
Now let's look into the security aspects.
This picture, I guess, is very familiar to most of you.
It outlines the so-called Shared Responsibility Model.
On the lower part, you see the responsibilities
of the cloud service provider, which
deal with the so-called security of the cloud.
This covers, typically, the data centers, physical hardware
network up to the hypervisor level, but also the cloud
services itself.
And also, the IT processes in the back--
things like access management, incident management,
or capacity management.
On top of that, you have the security in the cloud.
This is our responsibility as a customer.
So we have to make sure that we provide
secure access into the cloud.
We have to define appropriate roles.
We have to define security guard [? trades ?] to make sure
that we don't compromise on the high level of security
when we move into the public cloud.
Typically, the lower part is tackled
by looking at external certifications,
external reports, like all ISO 27000,
SOC [? 2.2 ?] reports, and so on.
But the regulator made it crystal clear to us
that only looking at these kind of certifications
and attestations by the better party providers
is not sufficient.
They deem the use of cloud services
similar like the classical outsourcing,
and hence, we need to have the same control
mechanisms in place.
And one of them is that we need to have an unrestricted right
to audit, that we really can uncover and look
into the details how the cloud service
provider is implementing all the required security controls.
Now, if you would do this alone, this would mean a lot of effort
for us, because as you have seen previously,
we work with a lot of different cloud service providers
together.
And an audit is typically an engagement
which takes a couple of weeks or even months,
and you'll need a lot of people in order to do so.
On the other side, there's also a lot
of effort for the cloud service provider,
because it's not only us having this unrestricted right
to audit, but in the end, all institutes in the same area.
So for example in all the financial service institutes.
Hence, we came up a couple of years
ago with the idea of a collaborative audit group.
The collaborative audit group is an open format,
where financial service institutes jointly
together conduct an audit with the cloud service provider.
This has been proven in 2017 the first time,
in a small proof of concept.
Then 2018 was really the first large-scale audit conducted.
And in 2019 also, Google Cloud platform
was audited by the collaborative audit group.
Currently, there is round about 40 different financial service
institutes in the collaborative audit group, but as mentioned,
any financial institute can join herein.
For the security in the cloud part,
we based ourself on the ISO 27001 framework.
Together with our information security colleagues,
we identified seven focus domains,
where we put a lot of effort into implementing security
controls to achieve the high level of security which
we are known for our on-premise infrastructure, as well.
So the focus domains are here shaded in blue, and cover
things like asset management, access control, cryptography,
and so on.
So we concluded with our colleagues
that we needed 20 different initiatives in order
to implement all the required controls to cover dimension
as a domains.
So as you can see, this is pretty much
a mix of where we extend over the existing solutions.
A good example is the cyber [INAUDIBLE]
for privileged access management,
or where we identified the cloud native services
as appropriate-- for example, in the area of key management
and sequence management.
Sometimes, also we identified that there
is neither a solution on-premise available
nor a cloud [INAUDIBLE] solution available,
and we did an evaluation of a new tool.
A good example here is AquaSec for compliance checking
of containers in our Kubernetes setup.
Now, as you can see, applying security in the cloud
is a lot of effort.
It's a lot of effort because, on one side,
there's always new requirements coming
from the regulators and new security threats out there.
And on the other side, also the cloud service providers
are always offering new services and new possibilities.
But what we found is that in the end,
applying security in the cloud is something which
is the same for every client.
So it's not only us doing the configuration,
doing the security guard [INAUDIBLE] configuration,
the role definition, and so on.
And yet, every client, at least under the same regulation,
has to redo the same effort.
And we thought, how could this be made more efficient?
And the idea we discussed with Google
here is that the cloud service provider could take back
some part of the responsibility of the security in the cloud
by providing things like certified landing zones, which
are compliant by default.
And I think this not only increases the security posture
for the clients and puts down the barriers of moving
really critical workloads into the cloud,
we think this is also increasing the overall security
culture for Google.
And this is why we came into close discussion with Grace.
And thankfully now, I'll hand over for her to continue.
GRACE MOLLISON: Thank you, Christian.
So Christian called out some focus domains
from the 14 controlled domains in ISO 27001.
Google Cloud is able to provide guardrails and controls
to address these with native tooling, as well as being
able to integrate partner solutions to help
with implementing the controls.
I'm just showing here some native ways
to help meet the requirements, but we have a rich partner
ecosystem that can also help so you can leverage your existing
investment in those partner solutions.
Today, however, I'm going to focus
on responding to these challenges Christian set up.
How do we address security in the cloud
for many customers, who all have different business goals
and applications?
How do we make it efficient to address?
How do we clearly distinguish who does what
in a shared responsibility model,
and what about certified landing zones?
So Christian is right.
It's the same challenge for every customer,
and taking a cross-sample of the questions we've been asked,
you can see that other customers are asking the same things
Christian has asked--
can I run my regulated workload?
What products are certified for the regulational standard
I need to comply with?
What do I need to do to achieve my security posture?
Our customers then say that we also want a single place
to find the assets we need to address our security posture.
We responded with the Google Cloud Compliance Resource
Center.
Security Health Analytics is an exception,
but I'll come back to that.
The Compliance Resource Center is the way
to find Google Cloud's compliance offerings by region
and industry, with best practices and documentation
to support your compliance reporting needs.
You can gain access to Google Cloud's attestations reports
to confirm compliance with a variety of standards
and regulations.
Google Cloud provides a variety of security
guidance to help customers deploy and develop
with a security-first mindset.
Customers can satisfy themselves that they can meet the security
requirements by Google Cloud providing guidance
and the ability for customers to implement
the guardrails required.
We want to provide prescriptive guidance and easily-deployable
assets which collectively are security blueprints.
Christian, you may recall, said what
the idea of a blueprint where the CSP, i.e., the Cloud
Service Provider, takes part of responsibility
within the cloud, and also provides certified landing
zones that are compliant by default. So we do
have security blueprints.
Google Cloud's definition of the blueprint
provides a package of documentation and assets,
which can be consumed all stages of the customer lifecycle.
The intended users are folks working
in the customer's compliance and governance function, and also
security administrators.
They may be of interest to other users, business or technical,
to determine, for example, if certain use cases are feasible.
A blueprint package varies in size,
based on complexity of the use case.
So Google Cloud has two types of security blueprints--
compliant landing zones-- for example, GKE for PCI--
and product and workload focus, such as those
to Anthos, or for your [INAUDIBLE]
the warehouse pipeline.
The compliant landing zone blueprints have more components
than the workload focus blueprints,
but both types have the core components that
are the what, which explains what controls you need
and what you need to do, and the how,
which are the deployable assets and instructions.
The first compliant landing zone blueprint published
is PCI for GKE.
GKE is a Google Kubernetes Engine.
This has a number of deployable assets,
available in a Github repo, provides
comprehensive guidance, includes things like a quick start,
pre-rec so you can configure your workstation, and diagrams,
and lots of them help known issues and limitations
and helpful links.
Our first product-specific blueprint collection
is for Anthos.
The first three are published.
And we are working on more.
Let's take a closer look at one of the blueprints
in the collection, Locality-Restricted Workloads,
but first up, I'll give you a short overview of Anthos.
Anthos is an open and hybrid cloud application platform,
which basically is managed Kubernetes for GKE.
It allows you to run GKE where you need to-- on Google Cloud,
on Premises, or another cloud.
It provides a consistent way to manage your GKE clusters
in a secure manner.
Anthos has a security-first approach.
It provides an auditable and centralized workflow
to deploy conflict changes, which both your security admins
and operations team [INAUDIBLE].
It allows you to enforce compliance.
Anthos service mesh, which is a key part of the Anthos
platform, abstracts some of the lower-level
security actions needed to secure
your microservices with MTLS and certificate management.
Now, this isn't a session on Anthos,
so don't worry if you don't know what all these things I'm
showing you here are.
The key thing is that to be able to configure your Anthos
environment to meet your locality restriction
requirement, to enforce where your applications are deployed
or where they can be accessed from,
you need to consider a number of things,
such as where your services are located,
and you need to configure a number of other things
to address these considerations.
So making a simple prescriptive to configure
is the aim of the security blueprint.
To provide prescriptive guidance to help
our customers secure their applications takes a village.
It starts with our customers, you know,
so we work with our engineering teams, UX designers, and tech
editors to show we're delivering guides
that are not too jargon-heavy, but validated and easy
to consume.
In effect, we partner with our customers
so the guidance we are providing is not creating a bubble,
and has customer input from the beginning of the process.
But we didn't actually stop at blueprints.
Our customers want to know what Google Cloud products are
compliant with a given standard, the shared responsibility
model, and what steps they need to take to configure
those products so they comply.
So the Security Command Center is the answer to that.
It's the canonical security and risk database for Google Cloud.
It is an intuitive, intelligent risk dashboard and analytics
system for servicing, understanding, and remediating
Google Cloud Security and data risks across an organization.
Note, though, it's not a substitute
for audit certification or reports
of compliance of your products or services,
with any regulatory or industry benchmarks or standards.
It's a guide to help you.
The key feature the Security Command Center
is Security Health Analytics.
In the Premium tier, it provides monitoring
for many industry-best practices,
and compliance monitoring across your Google Cloud assets.
These results can also be reviewed
in a compliance dashboard.
So here's an example of the Security Health Analytics
dashboard.
We're using in the Premium tier.
It's a single place to view how well you're
mapping against requirements.
Now, this is a mouthful, sorry about this--
the CIS Google Cloud Foundation 1.0 mappings have been reviewed
and certified by the Center for Internet Security for Alignment
for the CIS Google Cloud Computing
Foundation's benchmarks B1.0.0.
Additional compliance mappings are included for reference,
and are not provided or reviewed by PCI or the [INAUDIBLE]
Foundation.
And I just want to reiterate, as I said earlier,
it's not a substitute for audit certification or report
of compliance of your products or services
with any regulatory or industry benchmarks or standards.
Still looking at the Security Health Analytics
from the Findings page, you can click on the category,
and we'll provide guidance as to what you
need to do to remediate, OK?
So it's a powerful tool to help you.
So I just want to kind of bring it all together
and talk about the user journey to use these tools that I've
talked about.
You've just heard what Google Cloud has done in response
to our customers' request to make it easier,
by providing the Compliance Resource Center as the place
to go.
Customers have many personas involved
in ensuring that they meet the compliance security
requirements, so I just want to summarize
by walking through a typical customer's journey
through the Compliance Resource Center,
showing how the various personas interact with it.
So it normally starts with the CISO, in many cases, who
wants to check that Google Cloud can meet the desired compliance
regime, and maybe validation at this stage
what products are in scope.
If that gets the OK, then the security admins and architects
start looking at what Google Cloud could
be used for, and the configuration they need
to be in, by using the compliance map, Security Health
Analytics, and the blueprints.
And then the platform operations security
admins and devs, knowing what security postures need
to be met, can use the Security Health Analytics
and blueprints to achieve that when
they configure their environments
and deploy their applications.
So everyone in the journey to meet [INAUDIBLE]
compliance and security posture are using the same assets.
So thank you for listening, and I hope that was of some use.