Guide to Protecting the Confidentiality of Personally Identifiable Information

On Jan 13, 2009, NIST announced that draft Special Publication (SP) 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), <http://csrc.nist.gov/publications/PubsDrafts.html> is available for public comment. The guideline has been prepared for use by Federal agencies, also referred to as organizations in the guide. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

SP 800-122 is intended to assist Federal organizations in identifying PII and determining what level of protection each instance of PII requires, based on the potential impact of a breach of the PII's confidentiality. The publication also suggests safeguards that may offer appropriate protection for PII and makes recommendations regarding PII data breach handling.

NIST requests comments on draft SP 800-122 by March 13, 2009

The following recommendations are discussed within the document:

Organizations should identify all PII residing in their environment.

Organizations should apply the appropriate safeguards for PII based on the PII confidentiality impact level.

Organizations should minimize the collection and retention of PII to what is strictly necessary to accomplish their business purpose and mission.

Organizations should develop an incident response plan to handle breaches of PII.

Organizations should encourage close coordination among their privacy officers, chief information officers, information security officers, and legal counsel when addressing issues related to PII.

The document is organized into the following sections:

Section 2 provides an introduction to PII and lists some basic requirements involving the collection and handling of PII.

Section 3 describes factors for determining the potential impact of inappropriate access, use, and disclosure of PII.

Section 4 presents several methods for protecting the confidentiality of PII that can be implemented to reduce PII exposure and risk.

Section 5 provides recommendations for developing an incident response plan for breaches involving PII and integrating the plan into an organization’s existing incident response plan.

The following appendices are also included for additional information:

Appendix A provides samples of PII-related scenarios and questions that can be adapted for an organization’s exercises.

Appendix B presents frequently asked questions (FAQ) related to protecting the confidentiality of PII.

Appendix C contains definitions of common general terms related to private information.

Appendix D provides additional information about the Fair Information Practices that may be helpful in understanding the framework underlying most privacy laws.

Appendix E contains a FAQ pertaining to logging and verifying sensitive database extracts.

Appendix F provides a glossary of selected terms from the publication.

Appendix G contains a list of acronyms and abbreviations used within the publication.

Appendix H presents a list of resources that may be helpful to individuals in gaining a better understanding of PII, PII protection, and other related topics.

Will Massachusetts Data Security Standards Affect You?

On December 1st, 2008, Massachusetts issued a notice of a public hearing regarding extending the compliance date for certain provisions of 201 CMR 17.00: Standards for The Protection of Personal Information of Residents of the Commonwealth. This hearing is to allow public comment of the actions of November 14th when the Office of Consumer Affairs and Business Regulation extended the original deadline for compliance as follows:

• The general compliance deadline for 201 CMR 17.00 has been extended from January 1, 2009 to May 1, 2009. The date is consistent with a new FTC Red Flag Rule, which requires financial institutions and creditors to develop and implement written identity theft prevention programs.
• The deadline for ensuring that third-party service providers are capable of protecting personal information and contractually binding them to do so will be extended from January 1, 2009 to May 1, 2009, and the deadline for requiring written certification from third-party providers will be further extended to January 1, 2010.
• The deadline for ensuring encryption of laptops will be extended from January 1, 2009 to May 1, 2009, and the deadline for ensuring encryption of other portable devices will be further extended to January 1, 2010.

The provisions of this regulation apply to all persons that own, license, store or maintain personal information about a resident of the Commonwealth in either paper or electronic form.

In a nutshell:

These regulations are more prescriptive than HIPAA, GLBA and SOX, and less prescriptive than the Payment Card Industry Data Security Standards. HOWEVER, most organizations that have come into compliance with PCI DSS are only concerned with cardholder data, however 201 CMR 17.00 defines "Personal Information" in this fashion:

"A Massachusetts resident's first name and last name or first initial and last name in combination with any one or more of the following data elements that relate to such resident:

(a) Social Security number; (b) driver's license number or state-issued identification card number; or (c) financial account number, or credit or debit card number, with or without any required security code, access code, personal identification number or password, that would permit access to a resident’s financial account; provided, however, that “Personal information” shall not include information that is lawfully obtained from publicly available information, or from federal, state or local government records lawfully made available to the general public."

If your organization owns, licenses, stores or maintains personal information about a resident of the Commonwealth in either paper or electronic form, you should quickly determine what course of action your organization needs to take. You should take note of the "ensuring encryption of other portable devices" requirement.

Links from Office of Consumer Affairs and Business Regulation:

201 CMR 17.00 Compliance Checklist

Small Business Guide for Formulating a Comprehensive Written Information Security Program

Frequently Asked Questions Regarding 201 CMR 17.00

Some excerpts from 201 CMR 17.00:

Develop, implement, maintain and monitor a comprehensive, written information security program.

Every comprehensive information security program shall include, but shall not be limited to:
(a) Designating one or more employees to maintain the comprehensive information security program;
(b) Identifying and assessing reasonably foreseeable internal and external risks to the security, confidentiality, and/or integrity of any electronic, paper or other records containing personal information, and evaluating and improving, where necessary, the effectiveness of the current safeguards for limiting such risks, including but not limited to:

• (i) ongoing employee (including temporary and contract employee) training;
• (ii) employee compliance with policies and procedures; and
• (iii) means for detecting and preventing security system failures.

(c) Developing security policies for employees that take into account whether and how employees should be allowed to keep, access and transport records containing personal information outside of business premises.
(d) Imposing disciplinary measures for violations of the comprehensive information security program rules.
(e) Preventing terminated employees from accessing records containing personal information by immediately terminating their physical and electronic access to such records, including deactivating their passwords and user names.
(f) Taking reasonable steps to verify that third-party service providers with access to personal information have the capacity to protect such personal information, including

• (i) selecting and retaining service providers that are capable of maintaining safeguards for personal information; and
• (ii) contractually requiring service providers to maintain such safeguards. Prior to permitting third-party service providers access to personal information, the person permitting such access shall obtain from the third-party service provider a written certification that such service provider has a written, comprehensive information security program that is in compliance with the provisions of these regulations.

(g) Limiting the amount of personal information collected to that reasonably necessary to accomplish the legitimate purpose for which it is collected; limiting the time such information is retained to that reasonably necessary to accomplish such purpose; and limiting access to those persons who are reasonably required to know such information in order to accomplish such purpose or to comply with state or federal record retention requirements.
(h) Identifying paper, electronic and other records, computing systems, and storage media, including laptops and portable devices used to store personal information, to determine which records contain personal information, except where the comprehensive information security program provides for the handling of all records as if they all contained personal information.
(i) Reasonable restrictions upon physical access to records containing personal information, including a written procedure that sets forth the manner in which physical access to such records is restricted; and storage of such records and data in locked facilities, storage areas or containers.
(j) Regular monitoring to ensure that the comprehensive information security program is operating in a manner reasonably calculated to prevent unauthorized access to or unauthorized use of personal information; and upgrading information safeguards as necessary to limit risks.
(k) Reviewing the scope of the security measures at least annually or whenever there is a material change in business practices that may reasonably implicate the security or integrity of records containing personal information.
(l) Documenting responsive actions taken in connection with any incident involving a breach of security, and mandatory post-incident review of events and actions taken, if any, to make changes in business practices relating to protection of personal information.

Computer System Security Requirements

Every person that owns, licenses, stores or maintains personal information about a resident of the Commonwealth and electronically stores or transmits such information shall include in its written, comprehensive information security program the establishment and maintenance of a security system covering its computers, including any wireless system, that, at a minimum, shall have the following elements:

(1) Secure user authentication protocols including:

• (i) control of user IDs and other identifiers;
• (ii) a reasonably secure method of assigning and selecting passwords, or use of unique identifier technologies, such as biometrics or token devices;
• (iii) control of data security passwords to ensure that such passwords are kept in a location and/or format that does not compromise the security of the data they protect
• (iv) restricting access to active users and active user accounts only; and
• (v) blocking access to user identification after multiple unsuccessful attempts to gain access or the limitation placed on access for the particular system;

(2) Secure access control measures that:

• (i) restrict access to records and files containing personal information to those who need such information to perform their job duties; and
• (ii) assign unique identifications plus passwords, which are not vendor supplied default passwords, to each person with computer access, that are reasonably designed to maintain the integrity of the security of the access controls;

(3) To the extent technically feasible, encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data to be transmitted wirelessly.
(4) Reasonable monitoring of systems, for unauthorized use of or access to personal information;
(5) Encryption of all personal information stored on laptops or other portable devices;
(6) For files containing personal information on a system that is connected to the Internet, there must be reasonably up-to-date firewall protection and operating system security patches, reasonably designed to maintain the integrity of the personal information.
(7) Reasonably up-to-date versions of system security agent software which must include malware protection and reasonably up-to-date patches and virus definitions, or a version of such software that can still be supported with up-to-date patches and virus definitions, and is set to receive the most current security updates on a regular basis.
(8) Education and training of employees on the proper use of the computer security system and the importance of personal information security.

Visit us at www.ePrivacyAwareness.com or contact us at info@ePrivacyAwareness.com to get help with your Education and Training needs.

How Risky is your HR job application process?

How well does your organization manage risk within the domain of information security? The answer to that question probably depends on how well your organization knows where sensitive Personally Identifiable Information (PII) is collected and stored. There is one place that you should make sure you don’t overlook as you inventory your data – your HR job application process.

It’s surprising how many organizations collect social security numbers during the resume submission / job application process. I’ve found cases in both the public and private sectors:

Public Sector example:



Private Sector example #1: (note that the privacy policy for this site specifically said that they don't collect social security numbers over the web!!)



Private sector example #2: (hosted by a 3rd party)



In the case of the public sector, one of the recommendations that came out of the April 2007 President’s Identity Task Force Strategic Plan was on page 5:

"Decrease the Unnecessary Use of Social Security Numbers in the Public Sector by Developing Alternative Strategies for Identity Management

• Survey current use of SSNs by federal government
• Issue guidance on appropriate use of SSNs
• Establish clearinghouse for “best” agency practices that minimize use of SSNs
• Work with state and local governments to review use of SSNs"

It looks like the public sector has a lot more work on its hands in order to comply with the Task Force’s recommendations.

I suspect that the cases in the private sector are because of some old legacy collection methods (this is just a guess, I haven’t contacted these organizations) however when you consider the recent increase in web application attacks, all organizations should be looking at all applications that collect sensitive information over the web.

All of these organizations could benefit by using a process like Microsoft’s Security Development Lifecycle during software development or product acquisition. The SDL process has 14 stages across 7 phases (Training, Requirements, Design, Implementation, Verification, Release, Response). What follows is a brief summary of how an organization might use the SDL process to develop an application that collects applicant information over the web.

The Training Phase contains Stage 0: Security and Privacy Education and Awareness. There are many very good points that are made in the SDL book, here’s a summary of a couple:

If your company creates or uses software that stores or maintains sensitive or confidential data, your engineers must understand the basics of privacy.

All developers, testers, and program managers must complete one security training class each year.

The second point is critical. Attacks get better over time. Michael Howard provides a good example of this. In March of 2004, a white paper was published by Sanctum regarding HTTP Response Splitting, by August of 2004, Microsoft had to issue MS04-026 because it found OWA had this vulnerability. This is a perfect example of a threat that could never have been discovered before product release because no one knew it was a threat!

In the overall cost of software development, the cost of education (in terms of time and effort) is tiny; however, the risk of security errors being introduced without proper education is high.

The Requirements Phase contains Stage 1: Project Inception and Stage 2: Cost Analysis. Here is where you determine if the project should go through the SDL process, and if so, perform a security risk assessment to identify potential security risks and come up with a privacy impact rating. The Privacy impact ratings are P1 – High risk, P2 – Moderate risk, P3 Low risk.

The E-Government Act of 2002 requires all Federal government agencies to conduct a Privacy Impact Assessment (PIA) for all new or substantially changed technology that collects, maintains, or disseminates personally identifiable information. For organizations that aren’t required to create a PIA, the Sample SDL Privacy Questionnaire is a good starting point, and gives examples of P1-P3 ratings.

In our HR example, P1 would be triggered because it meets the following definition: “The feature, product, or service stores or transfers Personally Identifiable Information….” The outcome of receiving a P1 Privacy Impact classification is the requirement to review the guidance in the “Understand Your Obligations and Try to Lower Your Risk” section of the SDL Privacy Questionnaire. At this stage you probably would have attempted to estimate what percentage of individuals are asked to interview after submitting an on-line application and resume, and determine if the risk of collecting this information was really worth it. Higher risk translates to higher development and support cost.

This rating would also trigger the creation of a draft Privacy Disclosure, which would eliminate a situation where the Web Privacy Policy conflicted with what was really being collected.

The Design Phase contains Stage 3: Design Best Practices, and Stage 4: Risk Analysis. Here is where defining the security architecture and design guidelines and coding best practices like no SQL statements should be created using string concatenation, prepared statements should be used, and deny access to underlying tables and objects. Only grant access through stored procedures, and use libraries like AntiXSS. The Risk Analysis stage of this phase includes Threat Modeling and a review of the project with a Privacy expert if a high risk ranking of P1 has been assigned.

The Implementation Phase contains Stage 5: Creating Documentation and Tools for Users that Address Security and Privacy, and Stage 6: Establish and Follow Best Practices for Development. Here the coding, testing and integration occur. This is where secure build and code analysis tools are used such as Microsoft Source Code Analyzer for SQL Injection (MSCASI) , and the Cross Site Scripting tool, XSSDetect, FxCop, and others.

The Verification Phase contains Stage 7: Security and Privacy Testing, and Stage 8: Security Push. The software is functionally complete, and beta testing begins. Here is where you make sure that Security features and functionality cannot be circumvented, and threat models are updated as necessary. Finding bugs is the priority.

The Release Phase contains Stage 9: Pre-Release Phase: Public Release Privacy Review, Stage 10: Release Phase: Response Planning, Stage 11: Release Phase: Final Security Review and Privacy Review, and Stage 12: Release Phase: RTM/RTW. For our HR project, this is where all of the change management approvals occur to move the software into production.

The Response Phase contains Stage 13: Response Execution. This is where plans are put in place for what happens if something goes wrong, and what happens if there is vulnerability. Take a look at the sample SDL Privacy Escalation Response Framework document.

If your organization is using development processes based on Agile, you will find that the SDL will also fit into that environment. Details can be found in Chapter 18 of the SDL book.

A summary of where to find these stages in the SDL book can be found in the Sample Security Plan. By using a process like the SDL, you probably would have determined that you really didn’t need to collect that social security number, and saved your organization a lot of money during development, and eliminated potential breaches.

2008 Security Survey: We're Spending More, But Data's No Safer Than Last Year

An InformationWeek article indicates that companies are behind in implementing encryption to protect customer and employee data. The article also states:

"We had hoped that the ongoing parade of high-profile data losses would set most companies on the road to comprehensive privacy protection. So we were discouraged that the only actions to safeguard customer data that are used by more than half of companies are ... informing employees of standards and putting a privacy policy on the Web site. Fine steps, but they don't exclude the need for encryption (used by 34%) or privacy policy audits (25%). Amazingly, 11% say they have no privacy safeguards for customer data. Zip. Zero."

I think encryption is only one of the many steps you can take, an even better approach is to have risk management programs in place that allow you to understand what data you are collecting, and making sure you have a real business need to store it -- for example, why does your HR department even need all of the personal information they collect from a potential job applicant if they don't follow-up on 98% of the resumes they receive?

Understanding ways to mask and minimize the amount of data you collect, while still achieving the goal of the business should be the first priority of any organization's data owners.