[MUSIC PLAYING]
ANDY CHANG: Welcome to the Google Cloud Security Showcase,
a special web series, where we'll
focus on security use cases that customers
can solve with Google Cloud.
My name is Andy, and I'm a Product Manager
at Google Cloud.
Today, we'll be walking through one of the top questions we
get from customers.
How can I tell if I have missed configurations
or vulnerabilities in my GCP resources?
And how do I fix them?
The Cloud Security Command Center, Cloud SEC,
is a security management and data risk
tool for GCP resources that helps you prevent, detect,
and respond to threats from a single pane of glass.
To help you prevent threats, Cloud SEC
shows you resources that have been misconfigured
and provides recommendations on how
to fix them before an attacker can exploit them.
The first step is to see if you have any vulnerabilities
in your GCP resources.
You'll first need to go to the Cloud SEC security settings
and make sure the native detectors are enabled.
Here we've enabled both the Security Health Analytics
and the Security Scanner.
Once the scanners are on, they will
start assessing your GCP resources
for any vulnerabilities and service findings
to the Dashboard.
On Dashboard we can already see there
are findings from both Security Health Analytics and Security
Scanner.
First we'll explore the Security Analytics findings,
which show you the overall misconfigurations
in your infrastructure and GCP.
Here we see we have open firewalls, public buckets,
public IP addresses.
So let's dig into it a little bit more.
As we look at the underlying details,
we'll need to filter down from the different sources
to the ones that are specifically
for Security Health Analytics.
If we take the Security Health Analytics ID,
we can quickly reduce down to just the findings
that are related to Security Health Analytics.
As you can see, we have over 30 different detections
of misconfiguration we do out of the box.
So let's explore one of those open firewalls.
If we pick a particular open firewall,
this will tell you when the item was detected, what protocol--
in this case an allow all IP addresses was found for this
firewall--
what the actual explanation was, if this
was OK for that particular resource, what the customer can
do using security marks to actually whitelist
that particular resource for open firewalls,
the severity, which is something that we've
taken an initial approach and encoding,
and then also which detector.
Specifically, once we know that this is the open firewall,
we also provide you a recommendation around what you
should do and a direct link to reconfigure the resource.
So if we click on that link, that
takes us to the actual firewall rule.
We can hit Edit, and then go and disable it, in which case
we've now eliminated that open firewall.
At which point in time, the next time the scan occurs,
this particular detection will no longer trigger.
When we go back to the Dashboard,
we're able to see similar results on the Cloud Security
scanner, which is a web vulnerability
scanner on your applications which can be served either
in GCE, App Engine, or GKE.
And we'll find things like cross-site scripting,
outdated libraries, Rosetta flash, and a few other things.
If we now explore what we currently have under those,
we'll see that, for the Security Scanner
again, we'll want to filter on its parent type just
to reduce down to the sections that are related to it.
And you can see just the categories of items
that it finds.
If we go Explorer Specific one, like this Cross-Site Scripting
Callback, we're again taken to a detail page, which gives you
a description of what the issue was,
what asset that the issue was found on, when it occurred,
the detector that found it, and also the ability
to understand a little bit more about what the actual bug is.
We've also integrated this to take you
back to the actual project in which the detection was
created.
And you're able now to explore specifically
in that public firing range test the other vulnerabilities that
have been found.
And for the cross-site scripting ones,
we provide even more additional information
around each of the points where there is cross-site scripting
detected, [INAUDIBLE] vulnerability detected,
the ability for you to have a reproduction of that error,
what the actual error was, and the ability for you
to look and explore in more detail.
At this point do you have enough information
to provide to your development team
for them to explore the code and fix that vulnerability.
Thank you for tuning in.
Please visit cloud.google.com/security
for more content from Google Cloud experts.
[MUSIC PLAYING]