PRERNA BELLARA: Look, unicorns do exist.
STEPHANIE WONG: Psh.
We all know unicorns are mythical creatures,
whereas dinosaurs actually did graze the very land we're
standing on.
PRERNA BELLARA: OK, well, before we go back and forth
about our own existence, the real question of the decade
is, do you know where your sensitive data exists?
Or is it a myth that your PII and sensitive information
are going back and forth, and your company will never
be leaked?
STEPHANIE WONG: It sounds like we can prove
that that's actually a myth.
PRERNA BELLARA: Indeed, it is.
But Google's Data Loss Prevention API
can help classify and redact information at the source.
Enough of us talking.
Let's jump into a demo.
[MUSIC PLAYING]
So this is a great opportunity for talking about the Data Loss
Prevention API.
And it's a need of the hour, right?
In a way.
Because if you think about it, it's
reported that 2.5 quintillion bytes of data
are generated every day.
That's a lot of information, and a lot of sensitive information
that is generated by users and millennials like you
and I. In fact, I was told that 90%
of the data that we're using today
was generated just in the last few years.
Now, where does DLP come into play?
Whenever we're talking to our company in HR,
or whenever we're talking to our credit card
company or our credit score company,
we tend to exchange some sensitive information,
such as our phone numbers, our social security numbers,
ZIP code, date of birth, et cetera.
DLP helps you classify and redact information.
How does it do that?
DLP API will traverse through your raw data,
classify it into a social security number, phone number,
and--
there are about 40 or 50 types of classifications
like this that you can see on the website.
It redacts that information, and then
lets you use it for further analysis,
secure sharing within your company,
and for app development.
Let's look at an app development section.
There's a situation that we've all seen before, right?
There's a customer agent, and there's
Alice, who's a customer, who's trying to get an Anvil
application to work correctly.
Neil has asked her for the last four
digits of her social security number and contact information.
Alice has clearly overshared.
She's not only given her entire social security number,
she's given her email address and a photo
of her social security card.
Now, enterprises want to store this information
for further data analysis and improvement.
But if they store this, they're exposing
Alice's private information to the entire organization.
And they can potentially get sued.
Alice can potentially lose her social security
and her identity.
How do we fix that?
As soon as we click End Chat, our DLP API
runs in the background, traverses through this chat,
and redacts the information.
You can see that the phone number has been masked.
Her social security has been masked.
Only the last four digits have been maintained.
Her email address is completely blocked out.
And this is one of my favorite features.
The social security number, despite it being a photo,
the numbers have been masked.
And it's classifying it as a social security number, as well
as the likelihood that this is a very likely chance of being
a social security number.
Like that, you have others, like US Census names.
And all of this information can now
be stored very easily into their database.
Now, let's look at what it looks like behind the scene.
There's a Google Cloud Storage bucket.
Yes, it's in the cloud, which has all your raw data, right?
We're looking at an examples right now,
which has customer data, HR data, and a mix of data.
There's what the data looks like in real life.
There's a customer ID, their first name, last name,
and some comments.
These are just garbage comments, but you
can see that there are some numbers over there that
resemble a social security number,
or somebody's phone number, or a credit card number.
Let's see how DLP handles this information,
because when we're storing this information,
we don't want to store their email address
or their social security number.
All of this information, after it is run through DLP,
we store it into BigQuery.
This is what the data looks like after DLP
has redacted the information.
You can see it gives you the table name, the row number,
it tells you that it was in column comments,
and this was the value.
And it was an email address, and it was very likely
that it was an email address.
So now you know the row which has sensitive information
and the value.
So the next time you want to move this information
from one place to another, you will
be cognizant to remove the value or to be
wary of sharing this information, or at least
this row.
This was another query that our team came up with just
to show the number of occurrences of each attribute
type and the percentage.
This, again, is in BigQuery.
You can see it's a three-line query that's
just coming up with a small metric
that we have come up with ourselves.
STEPHANIE WONG: Wow, I don't know what's more magical--
you, or the DLP API.
PRERNA BELLARA: But don't be fooled.
The DLP API is not a myth.
It's an API, like the name suggests,
that prevents unauthorized users from sending
sensitive or unauthorized data.
STEPHANIE WONG: Can't get more real than that.
Thanks again, Prerna.
PRERNA BELLARA: Sure.
Please comment, like, and subscribe below.
STEPHANIE WONG: And if you'd like to get in contact with us,
check out the link below.
[MUSIC PLAYING]