[MUSIC PLAYING]
ANTHONY GUIDA: 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 Anthony Guida and I am a customer engineer
at Google Cloud.
Today, we'll be walking through one of the top questions we
get from customers--
How do I detect malicious activity
in my Google Cloud environment?
The Google Cloud solution that we will be focused on
during this session is Security Command Center, also known
as SCC.
SCC is inspired by the same technologies
that Google uses to protect itself.
We are now bringing this cloud-native technology
to the market so that you can utilize it
to protect your organization.
So how does Security Command Center work?
Well, as you can see in the slide,
SCC continuously monitors your Google Cloud environment
to discover assets, identify misconfiguration and web app
vulnerabilities, and detect threats in near real time.
SCC also provides you these key capabilities for you
to effectively manage security and risk.
There is an asset view that provides a real-time insight
into your resources and policies,
changes to your inventory, and the security findings
associated with each of those assets--
a consolidated set of security findings
that span across misconfigurations,
vulnerabilities, and threats to your Google Cloud environment.
It also gives you a prioritized set of security findings
that help you address critical security issues.
Another capability within SCC is a compliance view.
Compliance view enables you to view and know
where you stand by correlating all
its tracked misconfigurations and vulnerabilities
to industry standards like CIS, PCI-DSS, NIST 800-53, and ISO
27001.
It also provides compliance reporting segmented
by these standards that you can use
to track how your environment compares
with the technical controls of your relevant industry
benchmarks.
Security Command Center not only provides you
visibility, findings, and compliance report,
but it also gives you recommendations and remediation
steps for you to take action on the security findings
and compliance violations.
You can also integrate these findings
into your security ecosystem.
For example, findings can be sent
to a SOAR or SIEM platform for you to remediate or respond.
All of these capabilities are provided to you as a service
without the need to manage any infrastructure.
As I mentioned, one of the top questions
that I get from Google Cloud customers
is, how do I detect malicious activity in my Google Cloud
environment?
It's a great question.
The approach to detecting these types of attacks
are definitely different in the cloud than on-premise.
To answer that question, we are going
to perform an attack simulation today
and show you how SCC enables you to detect an attack that
uses several tactics, including the ones you see on the screen,
from initial access to exfiltration.
The first tactic will be focused on initial access,
as the attacker needs to gain access to the Google Cloud
environment.
In this case, the attacker obtains and abuses credentials
of an existing GCP admin account as a means
of gaining initial access.
Another method could be compromising
the endpoint of that GCP admin.
As we know, compromised credentials
may be used to bypass access controls placed
on various resources and systems within the network,
and may even be used for persistent access
to remote systems.
The attacker will then access a virtual machine
within the Google Cloud environment to further progress
through their mission.
Once the attacker gains access to the Google Cloud
environment, they will want to establish persistence.
In this case, the attacker will create a service account
with elevated privileges so that if their initial access gets
removed, they will essentially have
a backdoor to the environment to complete their mission.
This service account will also be
used to complete additional steps within the environment.
In order to detect this type of an attack,
SCC will be leveraging an anomaly detection technique
to identify when a service account grants
itself a sensitive IAM role.
Once the elevated service account is provisioned,
the attacker in this case will continue
to establish persistence to the environment
by implementing a binary into an existing Google Kubernetes
Engine cluster, which is another backdoor for the attacker
to use if their initial access is removed.
The binary that is implanted could
be used for various purposes such as establishing
a reverse shell.
For those familiar with running containers in their cloud
environments, they should know that runtime containers
are meant to be immutable.
Containers and the apps that run within them
go through an extensive CI/CD process
and should not change once they are running in production.
For example, binaries or libraries
should not be added to the cluster at this point.
So that means this is an excellent place
to perform detection.
The approach we take with SCC is by instrumenting the LSM
with what is called container threat detection.
So when you enable SCC Premium, the agent
is already baked into the container OS image
and does not increase the attack surface
in the container environment.
It is also very lightweight and does not
consume significant resources.
This is a major benefit of a cloud-native technology
such as SCC, as all of the analysis
is built into the control plane.
Excellent.
Now that the attacker has gained access to the Google Cloud
environment and established persistence,
they are going to move on to data
collection and exfiltration phases of their mission.
There are several techniques to collect and exfiltrate data.
Today, we're going to focus on Google's serverless data
warehouse technology, BigQuery, and a native capability
to export data to a Cloud Storage bucket.
Once the data is exported to the bucket,
the attacker will use that method
to effectively exfiltrate data from the GCP environment.
Just a quick recap of what we just walked through.
You can see the four tactics that we'll be simulating,
the techniques associated to them,
along with the MITRE Att&Ck technique numbers so that you
can reference them offline.
Now let's simulate this attack and then
demonstrate how you can detect these threats
and malicious activity using Security Command Center
Premium.
As mentioned, today's demo is going
to be focused on Security Command Center Premium.
I'm currently logged into my organization's Security Command
Center Console.
And as you can see, I'm filtering at the moment
based on the last hour.
You can change this filter up and down,
the timeline of what is provided, within this dropdown
menu.
For the purpose of this demo, we're
going to be focusing on the last hour.
As you can see, once you log into the Security Command
Center Console, we are surfacing findings by severity,
active vulnerabilities over time by severity,
and new threats over time.
You also have the ability to drill
into any of these findings by category,
resource type, or project, as noted on this overview page.
So we're going to simulate the attack
that we reviewed in the slides.
And for that purpose, I have a handy shell script
here that I'm going to execute that will
simulate all of the tactics and techniques that we reviewed.
So I'm going to go ahead and kick that off.
By running that script, that runs through the tactics
and techniques.
And in the meantime, I'm going to switch to Security Command
Center Console and go ahead and refresh my screen here
and demonstrate how quickly Security Command Center detects
these threats and malicious activity.
So I'll refresh this.
And as you can immediately see that within the last hour,
we've identified four new threats
from a critical severity perspective,
six threats from a high severity perspective,
and one low severity threat.
So we're going to click into the Threats tab
and identify the various threats that
have been categorized and detected by Security Command
Center Premium.
As you can see, several different findings
from adding binary executed to adding
a library, a reverse shelf technique that
was leveraged in this environment, BigQuery data
exfiltration, a persistence method that was associated
to the anomalous IAM role and the service account
granted itself that role.
And then lastly, some discovery techniques
that were also associated to the service account
performance, a self-investigation
on the permissions and privileges
that it had initially.
Any one of these findings can be quickly something
that can be pivot into them.
I'm going to select the reverse shell method just
to quickly demonstrate the information that has surfaced
with the actual finding.
So here we have a couple reverse shell findings.
I'm going to pivot into one of these
here and pull out the Summary information, including
a description, when it was first and last discovered
in the environment, the method that was used to actually
detect this particular finding-- in this case, Container Threat
Detection.
And then down below that, you have
all of the various attributes associated
to the cluster and the finding that this
was particularly relevant to.
In addition to that, we have a Source Properties tab
that goes into much more detail into the environment variables,
the IP addresses involved, the ports that were leveraged,
and so forth, associated to this particular finding, which
is a reverse shell finding that was detected
by container threat detection.
Any one of these drill downs can be further leveraged,
as you can see here.
And then lastly, you can share these findings
with additional team members if you
like by copying a link to this finding.
And as mentioned during the slide portion of this demo.
You could also send these details to some kind of SOAR
or SIEM platform and leverage those tools and technologies
to proceed with any type of remediation or response efforts
that are associated with that.
So this concludes our security showcase and demonstration.
Please check out cloud.google.com/security
for any additional demos and security showcase videos
relevant to your environment.
Thank you for listening in.
Appreciate your time.
[MUSIC PLAYING]