A short introduction and primer to managing PII.

1. Managing
Personally
Iden0fiable
Informa0on
(PII)
KP
Naidu
May
2011

2. What
is
PII?
 Personally
Iden0fiable
Informa0on
(PII)
is
any
informa0on,
maintained
by
a
company,
which:
• can
be
used
to
dis0nguish
or
trace
an
individual’s
iden0ty
• is
linked
or
linkable
to
an
individual
 Examples
of
PII:
• Name,
Address,
SSN,
Date
of
Birth,
Phone
Number
• Device
specific
sta0c
iden0fier
(e.g.,
IP
Address,
UDID,
etc.)
• Logs
of
user
ac0ons
• Financial,
Employment
or
Loca0on
data
Page:
2

3. PII
Data
Breaches
(2010/2011)
>
77M
Users
32M
Users
45
out
of
51
companies
surveyed
had
a
data
breach
in
2010
(Symantec
sponsored
study
carried
out
by
Ponemon
Ins0tute)
Page:
3

4. PII
and
the
Law
Page:
4

5. PII
and
the
Law
 US
Government
Ac0ons:
• Federal
Grand
Jury
inves0ga0ng
mobile
apps
and
the
data
they
transmit
about
user
ac0ons
• Boucher-­‐Stearns
draY
bill
• Rush:
Best
Prac0ces
Act
of
2011
(draY)
• Pending/current
state
laws
&
rules
regula0ng
use
of
PII
Page:
5

6. Other
Impacts
of
a
PII
Breach
 Loss
of
customers
 Revenue
loss
 Drop
in
customer
confidence
 Adverse
publicity
 Departure
of
key
employees
Sony
execu0ves
apologize
aYer
recent
data
breach
Average
cost
per
compromised
record:
$266
Page:
6

7. Steps
to
Managing
PII
 Assess
Confiden0ality
Impact
Levels
for
PII
collected
and
used
by
the
organiza0on
 Implement
Appropriate
Controls
• Opera0onal
Safeguards
• Privacy
Safeguards
• Security
Controls
 Prepare
Incident
Responses
for
Data
Breaches
Page:
7

8. Confiden0ality
Impact
Levels
-­‐
I
 The
confiden0ality
of
PII
should
be
protected
based
on
its
impact
level.
Items
of
PII
which
do
not
need
protec0on
include:
• Publicly
available
informa0on
(phone
book)
• Informa0on
voluntarily
shared/disclosed
• Informa0on
that
organiza0on
has
permission
or
authority
to
release
publicly
 Assess
the
harm
caused
by
a
breach
of
confiden0ality
• Individual
Harm:
Relates
to
adverse
affects
experienced
by
an
individual
when
a
breach
of
confiden0ality
occurs
with
their
PII
• Organiza>onal
Harm:
This
may
take
the
form
of
financial
losses,
loss
of
public
reputa0on
and
public
confidence,
legal
liability
and
addi0onal
administra0ve
work
Page:
8

9. Confiden0ality
Impact
Levels
-­‐
II
Impact
Level

LOW
MODERATE
HIGH
Impact
Type

Limited
Mission
capability
Significant
Degrada0on
Severe
Degrada0on
Degrada0on
Organiza0onal
Assets
Minor
Damage
Significant
Damage
Major
Damage
Financial
Loss
Minor
Significant
Major
Significant;
does
not
Catastrophic;
involves
Harm
to
Individuals
Minor
involve
loss
of
life
or
loss
of
life
or
serious
serious
injuries
injuries
Page:
9

10. Confiden0ality
Impact
Levels
–
III
The
following
factors
must
be
considered
while
determining
impact
levels:
 Iden>fiability:
Evaluate
how
easily
PII
can
be
used
to
iden0fy
specific
individuals
• SSNs
can
uniquely
and
directly
iden0fy
individuals
(High)
• Zip
Code
or
Date
of
Birth
can
significantly
narrow
a
list
(Moderate)
 Quan>ty
of
PII:
Consider
how
many
individuals
are
iden0fied
in
the
informa0on
• 25
records
(Low)
versus
2
million
records
(High)
 Data
Field
Sensi>vity:
Evaluate
the
sensi0vity
of
each
individual
PII
data
field
as
well
as
sensi0vity
of
the
fields
together
• An
individual’s
SSN
is
more
sensi0ve
than
his
phone
number
• A
combina0on
of
name
and
address
is
more
sensi0ve
than
either
one
by
itself
• Some
data
fields
have
higher
poten0al
for
harm
when
used
in
contexts
other
than
their
intended
use.
E.g.,
mother’s
maiden
name,
place
of
birth
are
oYen
used
to
recover
account
passwords
Page:
10

11. Confiden0ality
Impact
Levels
-­‐
IV
 Context
of
Use:
This
is
the
purpose
for
which
PII
is
collected
and
used
• E.g.,
providing
services,
behavioral
analysis,
evalua0on
of
preferences,
serving
up
ads,
sta0s0cal
analysis
or
law
enforcement
• Important
for
understanding
how
disclosure
can
harm
individuals
and
the
organiza0on
• Relevant
to
evalua0ng
impact
to
different
categories
of
people
–
list
of
newslemer
subscribers
compared
to
list
of
law
enforcement
officers
 Obliga>on
to
Protect
Confiden>ality:
• There
may
be
legal
or
contractual
obliga0ons
to
protect
PII.
The
collected
PII
may
being
assigned
higher
impact
levels
as
a
result
 Access
to
and
Loca>on
of
PII:
Factors
to
consider:
• Number
of
people
who
have
access
to
PII
• Frequency
of
access
• Remote,
offsite
or
offshore
access
or
backups
• Accessed
or
carried
around
by
mobile
workers
Page:
11

12. Opera0onal
Safeguards
 Create
Policies
and
Procedures
in
the
following
areas:
• Access
Rules
for
PII
• PII
Reten0on
Schedules
and
Procedures
• PII
Incident
and
Data
Breach
No0fica0on
• Privacy
in
the
SDLC
process
• Limita0on
of
collec0on,
disclosure,
sharing
and
use
of
PII
• Consequences
for
failure
to
follow
these
policies
 Training
and
Educa0on:
• Designed
to
change
behavior
or
reinforce
PII
prac0ces
• Focus
amen0on
on
protec0on
of
PII
• Updates
on
the
latest
scams
and
breaches
and
their
impacts
• Examples
of
how
staff
involved
in
inappropriate
ac0ons
have
been
held
accountable
• Examples
of
recommended
prac0ces
• Specific
role-­‐based
training
Page:
12

13. Privacy
Safeguards
-­‐
I
 Minimize
the
Collec0on,
Use
and
Reten0on
of
PII.
This
is
the
“minimum
necessary”
principle
• Collect
only
those
items
of
PII
which
are
essen0al
to
meet
the
organiza0on’s
business
purpose
• If
PII
serves
no
current
purpose,
then
it
should
no
longer
be
collected
and
used
• Check
if
previously
collected
PII
is
s0ll
relevant
and
necessary.
If
not,
then
the
PII
must
be
properly
destroyed.
Ensure
that
destruc0on
conforms
to
any
legal
or
contractual
requirements
 Conduct
a
Privacy
Impact
Assessment
(PIA).
This
is
a
structured
process
to
iden0fy
confiden0ality
risks
at
every
stage
of
SDLC.
Collect
details
of:
• PII
to
be
collected
• Reason
for
collec0ng
this
PII
• The
intended
use
of
the
PII
• How
the
PII
will
be
secured
Page:
13

14. Privacy
Safeguards
-­‐
II
 De-­‐Iden0fying
Informa0on:
• Full
data
records
not
always
required.
E.g.,
correla0ons,
trend
analysis
• Obscure
enough
PII
so
that
remaining
informa0on
does
not
iden0fy
an
individual
• May
be
re-­‐iden0fied
via
a
code
or
algorithm
assigned
to
each
record
• Re-­‐iden0fying
code
or
algorithm
should
not
be
derived
from
other
related
informa0on
about
the
individual
• Means
of
re-­‐iden0fica0on
should
only
be
known
to
authorized
staff
and
not
disclosed
to
anyone
without
the
authority
to
re-­‐iden0fy
records
• Can
be
assigned
a
PII
confiden0ality
impact
level
of
LOW
provided
the
following
condi0ons
are
both
true:
 The
re-­‐iden0fica0on
algorithm
or
code
is
maintained
in
a
separate
system,
with
controls
to
prevent
unauthorized
access;
and
 The
data
elements
are
not
linkable,
via
public
records
or
other
reasonably
available
external
records
in
order
to
re-­‐iden0fy
the
data
Page:
14

15. Privacy
Safeguards
-­‐
III
 Anonymized
Informa0on:
• De-­‐iden0fied
informa0on
for
which
a
code
or
algorithm
for
re-­‐
iden0fica0on
no
longer
exists
• Informa0on
is
no
longer
PII
• Usually
involves
applica0on
of
disclosure
limita0on
techniques
like:
 Generalizing
the
Data
–
making
informa0on
less
precise
 Suppressing
the
Data
–
Dele0ng
an
en0re
record
or
certain
parts
of
a
record
 Introducing
Noise:
Adding
small
amounts
of
varia0on
into
selected
data
 Swapping
Data:
Exchanging
data
fields
of
one
record
with
the
same
data
fields
of
another
similar
record
(e.g.,
swapping
ZIP
codes
of
two
records)
 Replacing
data
with
the
average
value
–
replacing
a
selected
value
of
data
with
the
average
value
for
the
en0re
group
of
data
• Useful
for
system
tes0ng
since
realis0c
proper0es
are
retained
Cau>on:
PII
used
in
test
environments
requires
the
same
level
of
protec0on
as
in
produc0on
environment
Page:
15

16. Security
Controls
-­‐
I
Specific
security
controls
should
be
established
to
ensure
confiden0ality
of
PII
 Access
Controls:
• Iden>fica>on
and
Authen>ca>on:
Users
must
be
uniquely
iden0fied
and
authen0cated
prior
to
accessing
PII.
Typically,
two-­‐factor
authen0ca0on
is
required
as
well
as
a
0me-­‐
out
func0on
for
remote
access
• Enforcement:
Control
access
to
PII
through
role-­‐based
access
control
to
allow
each
user
to
only
access
pieces
of
data
necessary
for
the
user’s
role;
or
allow
access
only
through
an
applica0on
which
0ghtly
restricts
access
to
PII
• Least
Privilege:
Ensure
that
users
only
have
access
to
the
minimum
amount
of
PII,
along
with
those
privileges
–
read,
write,
execute
–
that
are
necessary
to
perform
their
work
• Remote
Access:
Prohibit
or
strictly
limit
access
to
PII.
If
remote
access
is
permimed,
ensure
that
the
communica0ons
are
encrypted
• Mobile
Devices:
Prohibit
or
strictly
limit
access
to
PII
from
portable
or
mobile
devices
because
these
are
generally
higher-­‐risk
than
non-­‐portable
devices.
If
access
is
permimed,
ensure
devices
are
properly
secured
with
up-­‐to-­‐date
an0-­‐malware
soYware
and
OS
patches
• Media
Access:
Restrict
access
to
media
(CDs,
USB
flash
drives,
tapes,
paper,
etc.)
containing
PII
Page:
16

17. Security
Controls
-­‐
II
 Separa>on
of
Du>es:
Enforce
separa0on
of
du0es
for
roles
involving
access
to
PII.
For
example,
users
of
de-­‐iden0fied
data
should
not
also
be
in
roles
that
permit
them
to
access
the
codes
needed
to
re-­‐iden0fy
the
records
 Monitoring
and
Audits:
• Monitor
all
access
to
PII
to
detect
unauthorized
access
events
or
amempts
• Monitor
PII
internally
or
at
network
boundaries
for
unusual
or
suspicious
data
transfers
• Regularly
review
and
analyze
system
logs
for
indica0ons
of
inappropriate
or
unusual
ac0vity
affec0ng
PII
and
inves0gate
suspicious
ac0vity
or
suspected
viola0ons
Page:
17

18. Security
Controls
-­‐
III
 Media
Handling:
• Marking:
Label
media
containing
PII
to
indicate
how
it
should
be
distributed
and
handled
• Storage:
PII
on
paper
or
on
digital
media
must
be
securely
stored
un0l
it
is
destroyed
or
sani0zed.
For
example,
encrypt
data
stored
on
storage
drives,
backup
taps
and
removable
media
• Transport:
Protect
media
and
mobile
devices
containing
PII
that
is
transported
outside
the
organiza0on’s
controlled
areas
• Sani>za>on:
Sani0ze
media
containing
PII
before
it
is
disposed
or
released
for
reuse
 Informa>on
Transmission:
Protect
the
confiden0ality
of
transmimed
PII
either
by
encryp0ng
the
communica0ons
or
by
encryp0ng
the
informa0on
before
it
is
transmimed
Page:
18

19. Incident
Responses
-­‐
I
Breaches
involving
PII
must
be
handled
differently
from
other
incidents
because
there
are
specific
features
and
risks
associated
with
breaches
involving
PII
which
may
not
be
associated
with
other
incidents.
 Prepara>on
• Integrate
response
plans
for
PII
breaches
into
exis0ng
incident
response
plans.
• Train
en0re
staff
on
policies
and
procedures
• Carry
out
simula0on
exercises
to
evaluate
whether
exis0ng
procedures
are
adequate
and
to
assess
whether
staff
are
able
to
perform
their
roles
as
required
• Employees
must
clearly
know
how
to
iden0fy
a
PII
breach
and
what
informa0on
about
the
breach
needs
to
be
reported
• Employees
must
be
able
to
report
any
breach
involving
PII
immediately,
24x365
• Iden0fy
person
or
commimee
(named
members)
responsible
for
coordina0ng
organiza0ons
response
Page:
19

20. Incident
Responses
-­‐
II
 Informa>on
to
be
collected
about
Breach
• Person
repor0ng
the
incident
• Person
who
discovered
the
breach
• Date
and
0me
the
breach
was
discovered
• Nature
of
the
incident
• Name
of
system
and
possible
interconnec0vity
with
other
systems
• Descrip0on
of
informa0on
lost
or
compromised
• Controls
in
place
to
prevent
unauthorized
use
of
compromised
informa0on
• Number
of
individuals
poten0ally
affected
• Storage
medium
from
which
informa0on
was
compromised
• Whether
law
enforcement
was
contacted
 Elements
of
Breach
No>fica>on
plans
• Whether
no0fica0on
to
affected
individuals
is
required
• Timeliness
of
the
no0fica0on
• Source
of
the
no0fica0on
• Contents
of
the
no0fica0on
• Means
of
providing
the
no0fica0on
• Who
receives
the
no0fica0on;
public
outreach
response
• What
ac0ons
were
taken
and
by
whom
Page:
20

21. Incident
Responses
-­‐
III
 Breach
Detec>on
&
Analysis
• Evaluate
all
incidents
to
check
if
a
breach
of
PII
is
involved
 Containment,
Eradica>on
&
Recovery
• Media
sani0za0on
may
be
required
when
PII
is
deleted
during
recovery
from
a
breach
• Check
if
PII
needs
to
be
preserved
for
evidence;
check
with
legal
counsel
prior
to
sani0zing
PII
• Use
forensics
techniques
to
ensure
preserva0on
of
evidence
• Determine
whether
PII
was
accessed
and
how
many
records
or
individuals
were
affected
 Post-­‐incident
Ac>vity
• Conduct
retrospec0ve
analysis
to
gather
key
lessons
• Share
informa0on
and
lessons
learned
within
organiza0on
as
well
as
with
external
agencies
as
required.
• Update
incident
response
plan
as
required
Page:
21

22. KP
Naidu
kpnaidu@gmail.com
Page:
22