Beyond Tech using PIAs 2011

Going Beyond Technology
Privacy Impact Assessments
from NIST
Candy Alexander, CISSP CISM
SecureWorld Expo Boston
March 24, 2011
Room 103

Candy Alexander CISSP, CISM - SecureWorld Expo - Boston March 24, 2011 - Room 103

Topics
 What is PII, PIAs and why should I care
 Using NIST’s guide
 How to define impact levels & safeguards
 Where should I begin
 Incident response
 Summary


What is PII
 Personally Identifiable Information
 Information which can be used to distinguish or
trace an individuals identity, such as their name,
social security number, biometric records, etc.
alone, or when combined with other personal or
identifying information which is linked to linkable
to a specific individual, such as date and place of
birth, mother’s maiden name, etc.”*

OMB Memorandum 07-16


OR more specifically…..
Personally Identifiable Information – refers to information that can be
used to uniquely identify, contact, or locate a single person or can be
used with other sources to uniquely identify a single individual.

The following are often used for the express purpose of distinguishing
individual identity, and thus are clearly PII under the definition used by
the U.S. Office of Management and Budget (described in detail below):
•Full name (if not common)
•National identification number
•IP address (in some cases)
•Vehicle registration plate number
•Driver's license number
•Face, fingerprints, or handwriting
•Credit card numbers
•Digital identity
•Birthday
•Birthplace
•Genetic information


Privacy Impact Assessment
Using the premise that all Personally
Identifiable Information (PII) is not created
equal or has the same value/risk
 PII should be protected from inappropriate
access, use and disclosure
 Provides a practical, context-based guidance for
identifying PII
 Define the appropriate level of protection for each
instance of PII
 Encourage close coordination among privacy, IT,
security and legal when addressing PII issues


Why is this approach so
important?
 Enables you to focus efforts and resources
on protecting the data that has the most risk
– rather than all
 Expensive and complex to protect the whole
environment
 Similar to the gold in Fort Knox; concentrating it in
one location & safeguarding it to the fullest


PIA Approach
1. Identify all PII residing in their environment

2. Categorize their PII by confidentially impact

3. Apply the appropriate safeguards for PII based on the
PII confidentiality impact level (i.e. how sensitive it is)

4. Minimize the collection/retention of PII to what is strictly
necessary to accomplish their business

5. Develop an incident response plan to handle breaches
of PII

NIST SP800-122* Process

Identify PII

Determine Confidentiality Impact Level

Apply Appropriate Protection Measures

Minimize Collection & Retention

Incident Response Plan for PII

*NIST SP800-122 – Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)


Identify PII within Environment
 What PII elements
 Name, Address, Social Security Number, Email, etc.
 Where are they
 Stored, processed and transmitted
 How are they used
 What is the business need
 Linkable
 Who
 Access
 “Custodianship”



 Based on “harm”
 Identified as
 Low
 limited adverse effect (minor harm - minor financial loss or no more
than an inconvenience )
 Moderate
 Serious adverse effect (significant harm that may result in significant
financial loss, but does not include loss of life, such as denial of
benefits, discrimination or potential blackmail)
 High
 Severe or Catastrophic adverse effect (major financial loss or server
harm to individuals such as life threatening injuries or loss of life)



 Evaluation Factors
 Holistic approach in evaluating data elements
 Complete view of data elements determine the
impact level
 5 factors used
 Distinguishability
 Aggregation and sensitivity
 Context of Use
 Obligation to Protect
 Access to and location of


1 - Distinguishability
 Unique id or not?
 SSN vs. Phone number (department phone)
 Listing of just SSNs?
2 - Aggregation and sensitivity
 Sensitivity of data when used together such as
 Name, address, SSN
 Name, address, SSN and data of birth
 May have requirement if SSN is involved, it is a
Moderate automatically



3 - Context of Use
 Purpose PII is collected , stored, used, processed,
disclosed or disseminated
 How could it be used or potentially be used (risk)
 The same PII used in different context may cause for
different impact levels
 Each “process” could have a different impact level on the
same PII data. For example: Name, address & SSN could be
moderate, but used for analysis of: alcohol or drug use, illegal
conduct, illegal immigration status, information damaging to
financial standing, and employability could make it a “high”



4 - Obligation to Protect Confidentiality
 Laws & regulations
 Privacy Act of 1974
 OMB memoranda
 HIPAA
 State Data Regulations
 Gramm-Leach-Bliley Act



 5 - Access to & Location of PII
 How many are accessing (staff & systems)
 Where they are accessing it from (remote
workers, onsite, vendors, etc.)
 Where is it stored (local on desktop/laptop or on
fileserver)



 How to get started?
 Form a team consisting of InfoSec, Privacy, IT,
“system owner” or info custodian and Legal
 Develop a form to help guide you through the
review and document the impact levels.
 Review the impact levels on a regular basis
 Similar to HIPAA



Form should include:
 Process Name:
 Process Description:
 Process Owner:
 PII data elements use:
 Distinguishability:
 Aggregation/Sensitivity:
 Context of Use:
 Obligation:
 Access to/Location of:
 Impact Level Declaration:
 Date of Declaration:


Going through the exercise – Example 1
 Incident Response Roster
 Data elements: Name, titles, office & work cell
numbers, work email addresses
 Distinguishability: small number (under 20)
 Aggregation/Sensitivity: internally available
 Context of Use: release would not likely cause harm to
individual or organization
 Obligation: none
 Access to/Location of: accessed by IT and response team; is
available to remote workers
 Impact level = Low


Exercise Example 2
 Intranet Activity Tracking
 Data Elements: user’s IP address, URL if website user viewed, date/time
user access website, amount of time user spent viewing, web pages or
topics accessed
 Distinguishability: by itself – no, but linked - admins can view this log and the AD
log to identify individual)
 Aggregation/Sensitivity: info accessed could cause embarrassment if related to HR
subjects, however amount of potential info is limited
 Context of Use: release of info would unlikely cause harm. Since logging is known
and assumed to happen – would not cause harm.
 Obligation: none
 Access to/Location of: Log data is accessed by small number of sys admins and
only accessible from Org’s own systems.
 Impact level = Low


Apply Appropriate Protection Measures
(Beyond Technology)

 Policy & Procedures
 Use of PIAs, access rules for PII, retention schedule,
redress, individual consent, data sharing agreements,
PII incident response, privacy in the SDLC, limitation
of collection, disclosure, sharing and use of PII
 Education, Training & Awareness
 What is PII, basic privacy laws/regs/policies,
restrictions on data collections/storage/use, roles &
responsibilities for using/protecting PII, appropriate
disposal, sanctions for misuse, recognizing a security
or privacy incident involving PII, retention schedules,
roles & responsibilities in responding to PII incidents



 Minimize to least amount necessary
 Reduce potential risk
 Review PII collection requirements regularly
 De-identifying Info (encryption/tokenization)
 Info that has enough PII removed/obscured such that
it does not identify an individual
 Full data records aren’t always necessary
 Can be accomplished by code, algorithm, or pseudonym
 Changes impact level to a low as long as:
 Re-identification is on a separate system with appropriate
controls
 Data elements are not linkable



 Anonymzing Information
 Making previously identifiable info de-identifiable
for which a code or other link no longer exists.
 Renders information so that it is no longer PII
 Generalizing the data
 Suppressing the data (redaction)
 Scrambling or swapping the data
 Useful in system development & testing


Incident Response Plan for PII

 Follow traditional IR planning
 Include Privacy & Legal
 Know you notification requirements
(State/Federal)


Questions?

Candy Alexander, CISSP CISM
calexander@ltcpartners.com

For a copy of this presentation, send an email request.


Beyond Tech using PIAs 2011

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Beyond Tech using PIAs 2011

Similaire à Beyond Tech using PIAs 2011 (20)

Beyond Tech using PIAs 2011