Managing Personally Iden0fiable Informa0on (PII) KP Naidu May 2011
Managing Personally Iden0fiable Informa0on (PII)
KP Naidu May 2011
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
Page: 2
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
PII Data Breaches (2010/2011)
45 out of 51 companies surveyed had a data breach in 2010 (Symantec sponsored study carried out by Ponemon Ins0tute)
Page: 3
> 77M Users
32M Users
Page: 4
PII and the Law
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
Other Impacts of a PII Breach
Loss of customers
Revenue loss Drop in customer confidence
Adverse publicity Departure of key employees
Page: 6
Average cost per compromised record: $266
Sony execu0ves apologize aYer recent data breach
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
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
Confiden0ality Impact Levels -‐ II
Page: 9
Impact Level LOW MODERATE HIGH
Impact Type
Mission capability Limited
Degrada0on Significant Degrada0on Severe Degrada0on
Organiza0onal Assets Minor Damage Significant Damage Major Damage
Financial Loss Minor Significant Major
Harm to Individuals Minor Significant; does not involve loss of life or
serious injuries
Catastrophic; involves loss of life or serious
injuries
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
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
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
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
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
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
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
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
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
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
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
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
Page: 22
KP Naidu [email protected]