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.

Updates to Microsoft Security Development Lifecycle

Microsoft introduced updates to its Security Development Lifecycle (SDL) Program in November. The updates include:

SDL Pro Network - a group of security service providers that specialize in application security and have been trained by Microsoft in the tools and guidance associated with its Security Development Lifecycle.

The one-year pilot program started in November 2008 and consists of nine companies (in alpha order):

Cigital Inc., Dulles, Va.
IOActive Inc., Seattle
iSEC Partners Inc., San Rafael, Calif.
Leviathan Security Group Inc. Westminster, Colo.
Next Generation Security Software Ltd. (NGS), Sutton, United Kingdom
n.runs AG, Oberursel, Germany
Security Innovation Inc. Wilmington, Mass.
Security University Inc., Stamford, Conn. - training services only
Verizon Business, Basking Ridge, N.J

Microsoft SDL Threat Modeling Tool 3.0 – Version 3 of the Microsoft SDL Threat Modeling Tool contains new features which include:

Automation: Guidance and feedback in drawing threat diagrams
STRIDE Framework: Guided analysis of threats and mitigations
Integration: Issue-tracking systems
Reporting capabilities: Security activities and testing in the verification phase

The tool requires Visio 2007, demo version or better for installation.

SDL Optimization Model




The update to this model is structured around five capability areas that roughly correspond to the phases within the software development lifecycle:

• Training, policy, and organizational capabilities
• Requirements and design
• Implementation
• Verification
• Release and response


Additionally, the model now defines four levels of maturity for the practices and capabilities in these areas—Basic, Standardized, Advanced, and Dynamic.








The SDL Optimization Model consists of an introduction, a self-assessment guide and three implementation guides, all contained within a single downloadable zip file in Microsoft Office 2007 format, which means that you will need Office 2007, or the Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats in order to view it.

The Introduction contains an overview of the SDL Optimization Model and how to use it.

The Self Assessment Guide contains a questionnaire for mapping your current secure development practices to the SDL maturity levels.

Three Implementer’s guides (Basic-Standardized, Standardized-Advanced, and Advanced-Dynamic) provide detailed and actionable guidance on the necessary steps for moving up the SDL maturity levels in each of the five capability areas.

Each Implementer’s guide contains valuable links to relevant publications, practices, tools, and checklists for Microsoft and Non-Microsoft development environments.

The goal of the SDL Optimization Model is to take security practices from a reactive to a proactive stance. That goal isn’t necessarily best reached by starting with the earliest phases. Peter Drucker once. said: “If you can’t measure it, you can’t manage it.”

Your organization may find it more effective to adopt the SDL by starting with improvements to incident response, and defect tracking which identifies security, privacy, and compliance related defects. Knowledge of incidents in the field will provide information regarding the kinds of issues that should have been tested for during verification. Defect tracking which identifies security, privacy and compliance related defects will allow you to identify and track concrete metrics and show measurable improvements as the process matures. These metrics will drive executive commitment and justify ongoing resources devoted to SDL optimization.

Spammer campaign exploits email read receipts

In the past month we have seen a new wave of malicious spam which relies on requests for delivery confirmations of unsolicited emails. http://www.scmagazineus.com/Spammer-campaign-exploits-email-read-receipts/article/119130/ This spam has 3 traps in it.

First, if you read the message and allow images to be displayed, the retrieval of the image will cause your email address to be placed in the spammers list of valid addresses.

Second, if you delete the email message, and don't have "ask me before sending a response" or "never send a response" turned on in your email tracking options tools menu, an email return receipt confirmation will be automatically sent to the spammer when you delete the message, verifying the validity of your email address.

Third, if you choose the unsubscribe or opt-out option contained within the email message, you will again cause your email address to be placed in the spammers list of valid addresses.

This highlights how important it is to disable the email preview option of your email application, especially if you don't block images from being loaded. Additionally, check how your email application handles read receipts/confirmations, you may be telling spammers that they have a valid email address simply by deleting the message, which will invite even more spam.

Certified Secure Software Lifecycle Professional

The (ISC)² launched a brand new certification program, the Certified Secure Software Lifecycle Professional (CSSLP) www.isc2.org/csslp. The CSSLP is designed to validate secure software development practices and expertise and address the increasing number of application vulnerabilities.

Code-language neutral, it will be applicable to anyone involved in the Systems Development Life Cycle (SDLC), including analysts, developers, software engineers, software architects, project managers, software quality assurance testers and programmers.

The following domains make up the CSSLP Common Body of Knowledge:

Secure Software Concepts - security implications in software development

Secure Software Requirements - capturing security requirements in the requirements gathering phase

Secure Software Design - translating security requirements into application design elements

Secure Software Implementation / Coding - testing for security functionality and resiliency to attack, and developing secure code and exploit mitigation

Secure Software Testing - testing for security functionality and resiliency to attack

Software Acceptance - security implication in the software acceptance phase

Software Deployment, Operations, Maintenance and Disposal - security issues around steady state operations and management of software

The CSSLP certification program joins a number of other existing certification programs:

IEEE:

Certified Software Development Associate (CSDA) and Certified Software Development Professional (CSDP) http://www.computer.org/certification

SANS:

GIAC Secure Software Programmer (GSSP) Certification (Language specific/secure coding, presently Java and C) http://www.sans.org/gssp/

ISSECO:

International Secure Software Engineering Council CSSE Certified Professional for Secure Software Engineering http://www.isseco.org/

When certified professionals are part of an SDLC program that incorporates secure processes and policies, significant progress is made in achieving software assurance.

Web Site design flaws

In August of 2008, JP Morgan Chase corrected a serious deficiency on their user logon frame. In the past, the secure account logon option was placed on Chase’s main web page, which was insecure.

Old website – note not https: enabled


The embedded Javascript code for the logon frame did submit the login and password information via SSL, however, the customer had no way to really know that this was happening in the background. Chase included a lock graphic within the embedded logon box, which increased the potential for confusion, and spoofing because most Web users are now taught to look for the lock on the browser’s toolbar.

Updated website – notice lock icon on toolbar


This deficiency had the potential of increasing the success of Phishing and man-in-the middle attacks on Chase’s customers, because a criminal could easily duplicate the page, and have embedded Javascript code send the information anywhere they wished without the customer’s knowledge.

Recently Professor Atul Prakash and doctoral students Laura Falk, and Kevin Borders from the University of Michigan published a paper titled “Analyzing Websites for User-Visible Security Design Flaws” which looked at 214 U.S. financial institutions for this type of flaw, along with four others. They found that more than 75 percent of the financial institutions had at least one of these design flaws:

1. Break in the chain of trust: Some websites forward users to new pages that have different domains without notifying the user from a secure page. In this situation, the user has no way of knowing whether the new page is trustworthy.

2. Presenting secure login options on insecure pages: Some sites present login forms that forward to a secure page but do not come from a secure page. This is problematic because an attacker could modify the insecure page to submit login credentials to an insecure destination.

3. Contact information/security advice on insecure pages: Some sites host their security recommendations, contact information, and other sensitive information about their site and company on insecure pages. This is dangerous because an attacker could forge the insecure page and present different recommendations and contact information.

4. Inadequate policies for user ids and passwords: It is important to maintain consistent and strong policies on passwords and user ids. We found some sites allow customers to use short passwords or they require e-mail addresses for user names.

5. E-Mailing security sensitive information insecurely: E-mailing any sensitive information is dangerous. We found that some sites offered to send statements and passwords through email but not very many people have secure e-mail.

While you are looking at your user authentication pages, think like a hacker. Is your user authentication page SSL enabled, but the rest of your site not? If so, does your application cause re-authentication to occur, thereby causing the credentials to be sent in the clear on the other pages? If your customer uses a hotspot, and you don't have an SSL enabled site, assume that all information can be intercepted and check to make sure you are not transmitting Personally Identifiable information on non SSL enabled pages.

With malicious attacks for profit on the rise, every organization needs to take a close look to see if they have any of these flaws on their website, and take quick action to correct it. However, if you don’t have time, don’t worry, the criminals do, and if they find a flaw, your customers will eventually call you.

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.