NIST Privacy Workshop Moves Forward with Framework Development

I attended the second National Institute of Standards and Technology (NIST) Privacy Engineering Workshop on behalf of ISACA, which was held in September in San Jose, California, USA. NIST took the information that they collected at their first workshop in April 2014 and put together a proposed high-level draft of the beginning of what will eventually become the privacy engineering framework—the “Preliminary Concepts” that will ultimately become integrated with the U.S. Framework for Improving Critical Infrastructure Cybersecurity, which was published early this year.

This workshop focused on four primary activities:

1. Reviewing the proposed privacy engineering definitions
2. Reviewing the proposed “System Privacy Risk Equation”
3. Determining a lexicon of privacy objectives, establishing common terms and categorizing potential privacy harms
4. Hearing from engineers, privacy experts and privacy advocates about additional issues

Proposed Privacy Engineering Lexicon
If engineers are expected to be able to understand privacy principles and then build privacy controls into their systems, devices and processes to effectively protect privacy, then they must be operating under a common vocabulary to understand the terms in the same way across the enterprise and then consistently implement the privacy controls. Some of the terms proposed by NIST, based upon their research and feedback from the April workshop, include three primary privacy engineering objectives and some primary privacy terms that all engineers need to know and understand.

The proposed privacy engineering objectives include (with my interpretations shown):

• Predictability: These are actions to support reasonable assumptions individuals have about how their personal information is collected, used and shared.
• Manageability: These are actions to allow individuals to access, correct, delete and selectively disclose their associated personal information as they determine to be appropriate.
• Confidentiality: These are actions to ensure only authorized access to personal information occurs.

There was also discussion of the need for a possible fourth objective: data subject disclosure and rights. However, as various speakers and attendees pointed out, this is something that could be a challenge to actually engineer.

A few of the key privacy terms proposed by NIST include:

• Data Actions: The typical information systems operations where personal information is involved.
• Problematic Data Actions: These are data actions taken with personal data that violate the objectives of predictability, manageability and confidentiality. For example, distortion, misappropriation and surveillance, just to name a few.
• Context: A critical term for engineers to understand. This is a concept that I emphasize all the time to my clients and in the classes I teach. It is also something most systems engineers do not take into consideration Context refers to the actions that should be taken based upon the reasons personal information is collected, and the ways in which it was intended to be used.

Defining Categories of Privacy Harms
NIST has proposed the following categories of privacy harms to be addressed by the privacy engineering framework.

• Loss of Self-Determination: These would include loss of autonomy, exclusion, and loss of liberty.
• Discrimination: These would include stigmatization and power imbalance.
• Loss of Trust: This would include situations where a breach of promises has occurred.
• Economic Loss: Direct financial losses resulting from identity theft and other misuse of personal information.

I firmly believe physical harm and safety should be another category added to the list. Here are just two considerations to support this.

1. We now have many devices that attach to individuals, and are used by individuals, to control their health, environment, etc. If the personal information and associated data within these devices was inappropriately accessed, used, altered, etc., it could result in physical harm to the associated individuals.
2. The types of surveillance methods and technologies continue to proliferate. They could be used to locate individuals, determine when individuals are alone, and reveal other aspects of an individual that could enable a malicious individual to bring harm to the individual in ways that could not occur without these surveillance methods and technologies.

Proposed System Privacy Risk Equation
NIST created a proposed “System Privacy Risk Equation” to help engineers to determine privacy risks in a similar way to how they use the information security risk formulas to determine information security risks. The big difference, though, is that the components focus on the likelihood of harm to the individuals involved, not to the organization itself. Which makes sense since the focus of privacy is on the individual.

The proposed System Privacy Risk Equation was presented as a diagram. Here is my interpretation in a more mathematical representation:

System privacy risk is the risk of problematic data actions occurring during
(Personal Information Collected or Generated +
Data Actions Performed on that Information +
Context)
= System Privacy Risk

One concept missing from this formula is stakeholder input. Without such input, it will be very hard to truly determine the associated privacy risk. I will look for this to be included in the updated equation, based upon discussions at the workshop.

Additional Issues to Address
In addition to the components of the proposed framework above, some of the additional issues that attendees expressed a need to add included:

• The need for basic privacy education for all involved with engineering privacy controls, in addition to providing detailed guidance documents and case studies
• Related to this, the need to educate the public on what is reasonable to expect from organizations with regard to preserving their privacy, and what they themselves need to take responsibility for
• The establishment of metrics to measure how well each of the privacy areas are being addressed within the organization, and to support a determination of an organization’s privacy program maturity model
• Addressing how engineers can include privacy actions within existing systems and software development models, such as agile and waterfall methodologies
• The need to shift the business view of privacy from being a compliance checklist responsibility to being a more holistic evaluation of privacy risks activity

You can download the documents containing the full details of the items discussed above, including the NIST proposed definitions, from www.nist.gov/itl/csd/privacy-engineering-workshop-september-15-16-2014.cfm.

Privacy is about the individual; security is about the business
A couple of recurring thoughts that were described during the workshop that are very important points for organizations to be able to effectively understand and then take appropriate actions to preserve privacy are:

1. The primary focus for privacy risks and mitigations generally is on individuals. This is different than the primary focus for information security, which generally is on the business.
2. Privacy must become part of the business culture and be addressed throughout every aspect of business activities where personal information is involved in any way.

Going Forward
This was an important next step toward establishing actionable privacy standards to include within the US Cybersecurity Framework to provide a reference that engineers will be able to effectively utilitize within their current systems and software development frameworks to help build in the controls currently missing that are needed to most effectively protect personal information and mitigate privacy risks. I do not see this as the last workshop, however; there were several issues that were left open and some that were not addressed at this workshop. NIST also emphasized that the privacy engineering initiative was a distinctively separate effort from the cybersecurity work, implying that there would be at least another workshop down the road.

I look forward to seeing the resulting NIST Interagency Report (IR) that Naomi Lefkovitz indicated would be created as a result of the workshop, and then attending the next workshop where the Privacy Framework likely will be finalized.

Rebecca Herold, CISA, CISM, CISSP, CIPP, FLMI
Owner & CEO, Rebecca Herold & Associates

[ISACA]