EMIL KINER: Hi, my name is Emil Kiner.
I'm the product manager for Google Cloud
Armor on the network security product team at Google Cloud.
Today, I'll be talking to you about how
to protect your applications from distributed
denial of service attacks as well as targeted web
attacks using Cloud Armor.
We'll start off with an overview of network security
in general on Google Cloud.
From there, we'll discuss all the latest
and greatest announcements and new
features that we've launched for Cloud Armor
over the past several months.
After that, we'll dive in and discuss in depth
how application protection and DDoS defense works.
And then we'll discuss some customer
use cases about how to protect your applications
in real-world scenarios.
Security follows a shared responsibility model
on Google Cloud.
We work to secure our network and infrastructure
and provide customers the tools necessary to do so
in their own projects.
We enable and encourage customers
to follow a defense-in-depth approach and deploy security
controls at various levels of their stack and infrastructure
to enforce access controls and ensure data
and mission-critical workloads remain private and secure.
On Google Cloud, we have several key network security controls.
Starting from the outside in, we have Cloud Armor,
the identity aware proxy, and the global load
balancers as our layer 7 controls
at the edge of the network.
Cloud Armor, in conjunction with the global LBs,
protect applications from DDoS attacks.
The Identity Aware Proxy is part of our BeyondCorp line
of products to allow access to internal applications
without needing a VPN.
Firewalls, in red, apply at the VPC level
and can be used to customize access for north-south traffic
as well as east-west traffic into, out of, or through VPCs.
Firewalls are used to define VPC boundaries
but can be as granular as per host.
VPC Service Controls, in blue, can
be used to control access to and from GCP services
and managed APIs, such as BigQuery or Cloud Storage
to or from the internet, VPCs, or on-premise sources.
In yellow, we have packet mirroring
that allows you to deploy a tap and mirror packets at the VM
or container cluster boundary to a configurable collector
destination.
Finally, we also support sending outbound traffic
through Cloud NAT as well as various interconnected VPN
options to enhance privacy and security.
Cloud load balancing is a critical component
of the end-to-end network security story.
We have three flavors of global load balancing-- the HTTPS load
balancer, the SSL proxy, and the TCP proxy.
The first two load balancers are SSL
terminating, meaning you are able to offload the SSL
termination and decryption to our edge proxies,
and we'll handle enforcing SSL policies upstream
of your infrastructure.
By uploading your certificates and configuring custom SSL
policies, you can ensure only pre-approved SSL/TLS
versions and ciphers are allowed on a per-VIP basis.
All of the global load balancers employ
a two-tier global anycast based system rather than
a DNS-based load balancing mechanism.
We broadcast the load bouncer's IP address globally,
and end user requests are routed to
and terminated at the geographically nearest point
of presence, or POP, to them.
From there, the request is coalesced and proxied
over Google's fiber backbone to the customer backend
in the geographically nearest region with available capacity.
At each stage of the process, we optimize on latency,
taking into account capacity if the underlying application
is deployed across multiple regions.
Cloud Armor is the web application firewall and DDoS
mitigation service, able to provide layer
7 protection and filtering for workloads deployed on GCP,
on prem, or with other infrastructure providers.
Cloud Armor is deeply integrated with the global load balancing
infrastructure and is able to inspect and filter
incoming requests after the SSL termination has occurred.
More specifically, with Cloud Armor,
customers are able to protect their HTTP-fronted applications
from DDos attack, filter incoming requests by geography,
or most L7 parameters, like request headers or cookies.
Moreover, as a web-application firewall,
Cloud Armor contains pre-configured rules
to prevent against the most common attacks
and vulnerability exploit attempts.
Users have access to real-time telemetry
in the form of logs sent to Cloud Logging containing
Cloud Armor's decisions on a per-request basis;
a monitoring dashboard that gives
granular views of allowed, denied, or previewed traffic;
as well as a correlated WAF security
findings that are sent to the Cloud Security Command Center.
As of March of this year, a rich set
of WAF capabilities for Cloud Armor
was made generally available.
Preconfigured rules can help mitigate
the OWASP top 10 risks.
We have ported over the mod security core rule set,
introducing rules to detect and block
SQL injection and cross-site scripting attempts as generally
available.
Additionally, rules for local file inclusion, remote file
inclusion, and remote code execution
are available as a beta.
The rest of the core rule set is targeted for release
over the course of this year.
With geo-based rules, customers can enforce access controls
based on the source geography of each request.
The IP-to-geo mappings are sourced from Google's own geo
team, so you can be sure of its accuracy.
We've also launched an extensible rules language
that allows users to configure custom layer 7 filtering
policies across request headers, request
parameters, and cookies.
Finally, Cloud Armor is now integrated with the Security
Command Center with Cloud Armor findings
as well as assets being sent to the CSCC dashboard
to alert defenders of potential attacks
against protected applications and websites.
We have recently greatly increased
the flexibility of Cloud Armor deployments
to protect an expanded set of customer infrastructure
on GCP as well as in hybrid use cases located on prem
or in other cloud providers.
Cloud Armor now supports protecting cloud CDM origin
servers by enforcing security policies on dynamic requests,
as well as cache misses destined for the CDM origin server.
Customer applications are often complex,
serving both cacheable static content as well as
dynamic requests from the same services.
With Cloud Armor able to inspect and filter requests
destined to CDN origin servers.
Users can now mitigate computationally expensive cache
busting attacks, as well as help protect
dynamic portions of websites and applications
from OWASP's top 10 risks.
Enterprises often need to enforce a consistent set
of security controls for their applications,
no matter where they are deployed, whether they
are migrating to GCP or running in permanently hybrid
configurations.
We recently launched support for internet network and point
groups that allows customers to leverage all of Google's Edge
infrastructure, including cloud load balancers, Cloud
CDM, and Cloud Armor to protect their website or application,
no matter where they are hosted.
Now Google can help protect year applications,
whether from DDoS attacks or other common web
attacks without having to deploy the application directly
on GCP.
Finally, GKE ingress support for Cloud Armor has recently
reached general availability.
GKE users can help protect their containerized workloads
by placing them behind the cloud load balancers
and configuring the Cloud Armor security policy for layer 7
filtering and WAF use cases.
Also we are proud to announce the availability
as a beta, a highly requested capability
to allow or deny traffic through a Cloud Armor security
policy based on a pre-configured, named IP list.
Many of our customers receive traffic into their GCP projects
from upstream service providers, such as other CDMs.
Prior to this capability, customers
would have to self-manage the list of IPs
from upstream providers to ensure
they can receive those requests through a Cloud Armor security
policy.
Now customers can configure a security policy
to deny all traffic from the internet by default
and allow only traffic from desired IP ranges
by referencing the named IP lists.
For now, the named IP lists are global in nature
and not user defined.
We are launching the beta with three launch partners--
Fastly, Cloudflare, and Imperva--
but intend to add the other service providers over time.
Finally, we are excited and proud to announce
the beta launch of Cloud Armor Managed Protection,
a set of DDoS mitigation and WAF services
offered at two service tiers, standard and plus,
which bundles together all of the features and capabilities
of Cloud Armor with additional value-added services,
all for an enterprise friendly, predictable
monthly subscription.
Last month, we published a blog post announcing
that Google had successfully detected and mitigated
the largest DDoS attack ever recorded to date.
Now, with managed protection Google Cloud customers
can leverage the same Edge capacity as well as
DDoS defense expertise to protect their own applications
and other publicly exposed workloads,
with a subscription plan that offers enterprise
friendly and critically predictable
pricing, which is not driven by incoming request volumes.
Cloud Armor WAF usage includes rules, policies,
and requests are included in the subscription plan,
meaning Cloud Armor monthly price will remain relatively
fixed, even if you are targeted by a high-volume layer 7 DDoS
attack that needs to be mitigated by Cloud Armor.
Over time, we will expand the services
offered in the plus tier, starting
with the upcoming Google-curated rule sets,
like the named IP lists announced previously.
For more information on managed protection,
please refer to the Cloud Armor blog announcing the beta,
as well as the product page for a sign-up form
to get more information.
On GCP, customers enjoy an unrivaled level
of DDoS protection from a wide variety of attack types.
It is important to understand that DDoS protection cloud
customers are able to receive is the same that
has been developed over the past 20 years
to protect and ensure availability
of Google's own services.
Thanks to the global nature of Google's network,
we are able to absorb and dissipate or otherwise
mitigate layer 3 and layer 4 network or volumetric attacks
across various components in our global load balancing
infrastructure.
The way this automatic mitigation works
is that all three types of global load balancers
will only proxy requests back to the customer backend
service when that request has completed a three-way TCP
handshake.
For volumetric and protocol-based DDoS attacks,
like UDP amplification or reflection, as well as
TCP floods, the TCP handshake is actually never established,
so we can safely drop this unwelcome traffic far upstream
of your infrastructure.
This happens automatically upstream
of customer infrastructure.
Next, Cloud Armor security policies
can be configured and attached to the load balanced
backend services to further provide
layer 7 application layer protection and access controls.
Cloud Armor security policies can
be configured to limit access based
on source IP or geo, a pre-configured WAF rule set,
as well as our fully customizable rules language
to craft custom layer 7 filtering policies.
Diving in a bit further, Cloud Armor security policies
can simultaneously invoke pre-configured WAF rules,
as well as user-defined rules to inspect request headers,
parameters, and cookies.
Policies are stored, evaluated, and enforced
at the edge of Google's network far upstream of customer's
infrastructure.
In the example on this slide, we have a policy
that first denies access to any external clients requesting
access to the admin portal of our example application.
Next, the Cloud Armor security policy
is configured to invoke preconfigured WAF rules
to detect and block known signatures for SQL injection
and cross-site scripting attacks,
which collectively have dozens of subsignatures
under the hood.
Finally, if the request is neither
targeting the admin portal nor containing
a SQL injection or cross-site scripting signature,
we will allow that traffic as configured
through the default rule.
Now, we'll discuss some example use cases for how customers
can protect their applications.
In order to protect your application
from volumetric and protocol-based DDoS attacks,
all that is necessary is to deploy one of the global load
balancers in front of your HTTP or TCP workload.
Once fronted by the load balancers, Cloud Armor,
in conjunction with the LDs, will automatically
mitigate DDoS attacks like DNS amplification attacks,
SYN floods, and other common layer 3, layer 4 DDoS attacks.
The only requests that will be proxy back to your applications
are ones that have completed the three-way handshake
and are well-formed layer 7 requests.
To add layer 7 protection for your applications,
the first thing you need to do is configure a Cloud Armor
security policy and attach it to the backend service that
is hosting the application or workload to be protected.
Cloud Armor security policies are used to customize access
to protected resources.
There is a one-to-many relationship between policies
and backends, meaning one policy can
be attached to multiple backend services,
but each backend can only have one security policy protecting
it.
Each policy consists of a prioritized list of rules
as well as a default rule.
As an incoming request tries to reach the customer backend
service, Cloud Armor will evaluate each rule
in priority order against the traffic.
The first matching rule will win,
meaning it will dictate the action to take--
allow or deny in this case.
If the traffic doesn't match any rules,
then the action configured with the default rule
will be applied to either allow or deny
the traffic through to the targeted backend.
Visibility and telemetry is key for
any comprehensive application protection solution.
Cloud Armor exposes this information
in near real time across several telemetry platforms
at Google Cloud.
Per-request logs are captured and sent
to Cloud Logging containing all decisions
that Cloud Armor makes with regard to layer 7 requests,
as well as which rules fired and why.
Real-time telemetry for request volumes
is available at various levels of granularity
through cloud monitoring in our preconfigured dashboard
to help you visualize and build the learning
policies against changes in traffic patterns.
Finally, correlated security findings
about unexpected traffic spikes are
sent to the Security Command Center
to trigger investigation and possibly
incident response workflows.
Putting it all together, here is an example
of a sophisticated use case that leverages the ability
to dynamically update Cloud Armor security
policies through our feature rich REST API or CLI.
Here, we see an application fronted by a cloud load
balancer with Google Cloud Armor enabled.
Telemetry is collected until monitoring and analytics
workflow, either homegrown by the customer,
commercial off-the-shelf, or using GCP's native data
analytics tools, such as BigQuery.
Other sources of telemetry and logging
are added to the system, including from the application,
from Cloud Armor, and other devices on the network.
Next, threat for fraud detection algorithms
will correlate the various telemetry
and generate additional signatures of malicious traffic
to block upstream.
These signatures can then be dynamically pushed
into the Cloud Armor security policy as a new rule
to quickly block the newly detected malicious behavior,
all at the edge of Google's network.
With that, I wanted to thank you for joining me today.
If you have any other questions, please check out
our recently published blogs or the product page.
And don't hesitate to reach out with any detailed questions,
and we'd be happy to follow up with you.
Thank you.