馃攳
GDPR & Salesforce 2018: Part I - Shield (Platform Encryption, Field Audit Trail, Event Monitoring, ) - YouTube
Channel: unknown
[0]
Ultimately, you know, we hope you get to this end state where when you think about GDPR you think
[3]
about it the way we do. We came, we saw, we kicked it's ass. Right. Welcome back!
[7]
RevCult Salesforce Security Series
[9]
Also really cool, having some international
[11]
participants. We're gonna be starting with privacy by design, data protection, and then
[16]
accountability. But what we try to do is
we kind of take these 88 pages of
[20]
craziness and boil it down to a few
primary themes. We see it as privacy by
[25]
design which is really kind of a small
area of the GDPR but if you back up a
[30]
little bit, it really goes throughout the
entire regulation. Just think about
[34]
privacy first, and none of the other
stuff is going to be a problem because
[38]
you thought about it early. Second is
accountability - taking responsibility for
[42]
people's privacy. And this is a human
element of what GDPR is. And then finally
[46]
individual rights and control - so content
management, right to object, the right to be
[51]
forgotten is kind of headline item, a
lot of people know about, and data
[54]
portability, so the ability to kind of
get information out of systems and move
[58]
it to other places upon request by the data subject. You know we put the blue
[62]
box around the top two because that's what we're gonna talk about in our part one
[64]
webinar today. Alright, so GDPR is not
[71]
de-spawn memory that you have from
childhood about this marshmallow that
[75]
then gets taken over by the dual, and
takes over the world, and is running
[78]
around the streets of Manhattan all over
the place. One of the things that we
[82]
hear that actually not ... Well
first things first, let's all be very
[86]
excited that it's not a hundred foot
tall marshmallow. That's frightening.
[91]
A lot of people say, you know hey, I'm not
storing Social Security numbers or
[94]
credit card numbers - I'm cool. Again GDPR
is very broad and so when it defines
[99]
personal information, it's really
anything that can identify a person - from
[103]
their name, to email address, to phone
number; and every single person that uses
[108]
Salesforce has personal information
in there because if you have users, you
[112]
have personal information. Why is it taking so long for people to really
[115]
proactively think about what they're
going to do in preparation for the
[118]
enforcement date? You know, I think our
theme here is it plays well with
[122]
our marshmallow man - it can be really
scary, but when it's something you don't
[125]
understand,
it feels so broad so everybody's like, I
[128]
don't even know where to start and now
it's to the point where it's like, okay,
[130]
well we have to start somewhere. You kick
the can down the road as long as you
[133]
possibly can and probably a little longer. Now let's talk about it as it relates to
[137]
Salesforce. Today we're going to really
focus on the elements that tie into
[142]
Salesforce shield. Shield ultimately has
three components, one has platform
[147]
encryption which natively encrypt
database, then we have event monitoring which
[150]
allows you to track the data from an
activity standpoint, and then finally
[154]
field audit trail which prevents data
loss. We've been having a lot of
[157]
conversation with both sets that are
doing the right things but then
[160]
ultimately they're not necessarily
going that final step of actually
[164]
deploying them in a way that addresses
the need to comply with an individual
[168]
article. Let's get into the details
article by article. Oh sounds like
[174]
fun! You guys want to read some GDPR? Now it's a party! Some of the articles that really
[178]
apply to what we're talking about in today's webinar, which really focuses on
[182]
privacy by design, data protection, and
accountability. We'll focus on other
[185]
attributes of GDPR later. I'll try to
distill them down in a way that you can
[189]
understand them and then take it
away and be able to actually act on it.
[193]
Twenty-five talks about the
privacy and protection by design
[196]
attribute. When you're designing a system
or you're implementing a system or a way
[200]
to store information or whatever it may
be, that you think about privacy first
[204]
and then by default it's as secure as
possible. And then thirty-two is just general
[209]
protection of data so it talks
about technical security, data
[215]
access controls and change control and
oversight. So let's talk about - from
[220]
this - what elements of shield can
kind of play into those two. GDPR is one
[225]
of the only regulation mention
encryptions; so platform encryption is a
[228]
great solution for that, it encrypts data at
the database tier all the way down on
[232]
the hard drives and it also can
help with some other attributes of
[236]
just the identifying sensitive personal
information so you can still store that
[241]
information but it's anonymized
at the database level. Event monitoring is
[246]
going to help you keep an eye on general
security measures, make sure that if
[250]
there's suspicious activity going on,
you're collecting the information you
[253]
need to be able to identify this as early
as possible and possibly prevent further
[257]
negative actions. And then field auto trail
is going to help you kind
[263]
of understand data resilience. In general what it means is the ability
[266]
to know what
happened with their information and the
[268]
ability to retrieve damaged information historically. So we look at the way those
[274]
three kind of interweave with articles twenty-five and thirty-two and I think they're great
[278]
solutions to help close that gap. Thirty-three and
thirty-four talk about breaches. If you
[283]
lose information you've got to tell the
individual and you've got to tell the
[287]
authorities. And thirty-three is to tell the
authorities and thirty-four is to tell the individual.
[292]
How can we overlay some tools to help
with that? From a shield perspective what
[296]
we can do is two things. We can
try to minimize the risk of a breach by
[300]
using platform encryption to make that
data unintelligible or kind of useless
[306]
at the database tier so if that data
was breached or extracted from the
[309]
database your breach may be
significantly less impactful if your
[313]
personally identifiable information was
encrypted at rest. Event monitoring will
[318]
also help you do some of that forensics
information to really know what the
[322]
severity was and so is it elevated to
the level that you need to notify the
[327]
data subject, which is what GDPR calls it,
or the individual person themselves.
[332]
And again they can help you identify
suspicious activity early so that you
[336]
can mitigate any further
exposure. Am I responsible for
[341]
notification of data - the data is
encrypted? If the data was extracted from
[346]
the database and it was encrypted at
rest then the information is effectively
[352]
useless. Assuming that they didn't gain
access to the key as well, which in the
[356]
case of platform encryption is stored
separately and you're good to go. So in
[361]
those cases you should be okay. Article five talks about what data can or
[365]
should be stored and for how long. Field Auto Trail is kind of our go-to;
[369]
it's native to the platform and it helps
you track history over time. It will help
[373]
you keep it long enough to be able to
provide evidence of what's occurred and
[377]
provides you a true daily resiliency but
be able to enforce data retention
[381]
policies to make sure you're not keeping
them too long. Article twenty-four talks
[385]
about controller responsibilities. There are these two terms you hear all the
[388]
time, processor and controller. If
you're using the information to do
[392]
business, you are the controller of the
data. A processor is anybody who helps
[397]
the person who needs the information to
do business, the controller,
[400]
do their business. Twenty-four is all about as a controller what do you need to
[404]
do; and one of the key aspects
of being a controller is knowing what
[409]
you have and being able to demonstrate
your policies. What we come back
[413]
to again on article twenty-four is its field
audit trail it helps you know
[417]
what's in the system and it helps you
provide that data resiliency and it
[421]
helps you be able to you know, prove, or
show,
[425]
hey I've implemented these data
retention policies, I've defined them,
[428]
I've implemented them, and I can
prove that the system is enacting on
[433]
them. There's also some other stuff that
you can do here around platform
[436]
encryption that didn't quite make it to the
slide, you know there's new encryption
[440]
statistics features built into
Salesforce in Spring '18 that ...
[444]
to prove for this field 100% of my
values are encrypted at rest in the data
[450]
tier with my loss current key.
Across-the-board shield is a enabling
[454]
solution for some of these core aspects
of privacy by design, data protection, and
[460]
accountability they see on the bottom is
a couple accelerators as I mentioned
[463]
earlier, we've got some products that
help people accelerate their
[466]
adoption and roll out of the shields
capabilities. One is shield security cockpit
[471]
and two is field audit trail cockpit - both in the app exchange, both have 5-star reviews. If
[475]
you're looking to move faster and not
going to do things easier internally,
[479]
those are tools that can certainly help. So
first question that came in... You know what
[484]
my favorite part is? What? Hat raffle.
[491]
My favorite part of the webinar! And as we do part two of GDPR
[498]
and Salesforce as part of our security
series, we're gonna be focusing on
[502]
the individual object and consent in a few weeks, so watch, keep track, and follow
[506]
us on LinkedIn and Twitter and
enjoying the next webinar to get more
[510]
details of how that actually works.
Most Recent Videos:
You can go back to the homepage right here: Homepage