[MUSIC PLAYING]
SPEAKER: BigQuery is a fully managed
petabyte-scale low-cost analysis warehouse.
You can access and share analytics insights
in your organization with a few clicks.
While BigQuery has robust security and governance
controls to keep your data safe within your organization,
it's important to keep sensitive data
inaccessible to unauthorized third parties
and reduce data exfiltration risks.
Event Threat Detection is a built-in service
for the Security Command Center premium
tier that continuously monitors your organization
and identifies threats within your system in near real time.
It includes a finding type for BigQuery data exfiltration,
which can help alert you when an unauthorized actor attempts
to extract or expose sensitive data in BigQuery,
whether on purpose or by accident.
BigQuery data exfiltration works by examining audit logs
for two scenarios--
a resource is saved outside your organization,
or a copy operation is attempted that's blocked by VPC Service
Controls, or an attempt is made to access
BigQuery resources that are protected by VPC Service
Controls.
In order to use BigQuery data exfiltration,
first enable Event Threat Detection with an SCC premium
subscription.
If you want to set up ETD, check out
our episode on how to use Event Threat Detection.
Let's imagine a malicious actor was tasked with stealing
the financial data set from the organization GCP-SEC-DEMO-ORG.
They attempt to push results to an external table located
in a different Google Cloud organization, project,
and BigQuery destination table.
If the GCP-SEC-DEMO-ORG organization did not have ETD
enabled, the malicious actor can quickly perform the query
and extract data to another project under a new table
if they have the right permissions.
While the action is logged, it happens mostly under the radar.
By the time someone notices, the job will be complete,
and the data has likely been exfiltrated.
Luckily, this organization has enabled ETD.
And when the malicious actor attempts,
ETD will surface the finding immediately,
including when it was discovered,
the category, under Source Properties,
the project found in, and data associated
with the exfiltration attempt including the detection
category and rules--
exfiltration to an external table, and jobState SUCCEEDED.
Below, you can find the destination BigQuery data set
and table IDs and the person who submitted the job.
The finding directly links to the job,
so that if the job had not yet succeeded,
you can now follow the link and stop the job before completion.
You can also add a VPC service perimeter
by heading to the VPC Service Control Console.
Service perimeters are an organization-level method
to protect Google Cloud Services in your projects
in order to mitigate the risk of data exfiltration.
Give it a name.
Leave perimeter type as default. And select Enforced
mode to prevent access to protected services.
Select the project, Restricted Services, BigQuery API,
VPC accessible services, Access Level, and click Save.
The idea is that the legitimate users of the data set
are aware of the perimeter violation.
If some malicious actor got access to the data set
but was not aware of the perimeter, attempting
to exfilltrate or even legitimately use
BigQuery at all would result in the violation
finding being generated.
Now, if the malicious actor attempts
to exfilltrate financial data from BigQuery
to an external table again, they are blocked.
VPC Service Controls-- Request is
prohibited by organization's policy, vpcServicecontrols.
Going back to the SCC threats page,
a new finding under the BigQuery Data Exfiltration category
has surfaced showing the VPC permanent violation.
Congratulations.
You've set up BigQuery data exfiltration
using Event Threat Detection for Security Command Center
and learned how to respond to a finding from it.
[MUSIC PLAYING]