TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout

""

""

Last week, the National Institute of Standards and Technology (NIST) hosted a workshop to discuss and develop the concept of privacy engineering. This novel workshop brought together speakers from both the public and the private sector. Although a great deal was covered, three topics recurred throughout the workshop and appeared to be of special interest to NIST:

  • the lack of technical standards concerning privacy,
  • the role engineers can play in protecting privacy
  • and the role NIST should play in the privacy field going forward.

Of note, there is a lack of clear standards that exist for regulating privacy. Central to this discussion was the more abstract nature of Fair Information Practice Principles compared to the straightforward, technical standards that NIST incorporated into the Preliminary Cybersecurity Framework. Speakers and attendees disagreed about whether it was necessary to view privacy as principle-based and cybsersecurity as standards-based, but NIST was clearly interested in the possibility of bridging the gap to some extent.

NIST officials acknowledged they had not yet done much to standardize privacy engineering and risk management models, and that process-oriented principles have not achieved consistent and measurable results in privacy protection. Given these concerns, it is fair to speculate that NIST is exploring how to better account for privacy in Section 4.9 of the Framework—although that goal was expressly dismissed during the workshop.

The second recurring topic was the role of engineers—and engineering—in protecting individual privacy and insulating organizations from liability. On this point, there was general consensus that engineers currently play a key role in ensuring that privacy is adequately safeguarded and will only become more vital as both systems and risks become more complex. Jonathan Fox (author of The Privacy Engineer’s Manifestoalong with the delightful Michelle Dennedy and Thomas Finneran) posited that innovation emphasizing privacy as part of the product life cycle is the way of the future.

Speakers and attendees disagreed about whether it was necessary to view privacy as principle-based and cybsersecurity as standards-based, but NIST was clearly interested in the possibility of bridging the gap to some extent.

Privacy experts and professionals—including one of the authors of this blog!—stressed the importance of organizational structure that emphasizes privacy, the value of developing a “culture of privacy” that raises every employee’s awareness of privacy issues and generally explained how to establish a privacy-protective environment. Individuals  in technical fields generally agreed, but noted the difficulties of training engineers to account for abstract privacy principles, as well as the responsibility of privacy experts to become more knowledgeable about technical issues. As David Hoffman clearly noted in our joint panel, “you can’t code ‘reasonable’”—which is frequently engineers’ initial reaction to privacy and its concept of a “reasonable consumer.”

Throughout the workshop, the role that NIST should play in the privacy field was the subtext of many discussions. NIST recently entered the privacy world with Appendix J of its Special Publication 800-53 in May 2013—after two and a half years of public comments on its efficacy with regard to FISMA compliance. I (Mary Ellen) may be biased, since one of my DHS colleagues labored on this for years as part of an inter-agency team, but I think Appendix J is an important milestone in the development of privacy and security integration.

With that said, should Appendix J translate to the private sector, or should NIST take a wider view of privacy engineering? Furthermore, should NIST and the Federal Trade Commission intersect on privacy standards? If so, how? These are open questions for now, but the workshop began to address some of them.

We think, ultimately, the workshop was a success, bringing the most pressing issues and concerns related to privacy engineering to the forefront and finding some unexpected points of consensus. Additionally, it provided a rare opportunity for individuals from both technical and policy backgrounds representing the public and private spheres to directly engage about issues significant to the future of privacy integration and development.

9 Comments

If you want to comment on this post, you need to login.

  • comment James • Apr 17, 2014
    So far I see nothing new here other than rehashing the old 'privacy by design' and 'developing a culture of privacy' tropes. To seriously discuss privacy engineering you have to do it in the context of engineering methodologies. I can't tell you how tired I am of lawyers with no engineering experience writing on this topic as if they were somehow competent to comment on engineering practice. 
    
    We need to introduce privacy into the engineering process. That means meshing it with the types of methodologies engineers use in developing products, as well as with the types of technologies used in the infrastructure of large-scale applications. 
    
    Trust me when I say that you lawyers do not understand the issues involved. The book by Dennedy et al is not about engineering. It is about 'engineering privacy policies', whatever that means. They use a simple app as an example. Fabulous. How exactly does that scale to highly distributed applications operating in highly complex socio-technical settings where you have thousands of users, complex interactions at various layers of the application stack, interfaces with other systems, etc etc.
    
    Note: "difficulties of training engineers to account for abstract privacy principles". Many of the data protection principles (e.g., OECD, CSA Model Code) are actually quite intuitive. The trick is in finding repeatable and reliable means of integrating privacy into engineering methodology.
    
    At any rate, I know the IAPP is overburdened with lawyers, but I have really had enough shallow commentary on privacy engineering from people with JDs who know nothing about engineering.
  • comment Jedidiah Bracy • Apr 17, 2014
    Hey James, you raise some great points, particularly meshing privacy into the methodologies engineers use to develop products and the types of tech used in the infrastructure of large-scale applications. Would you care to expand upon these ideas about privacy and engineers in a Perspectives blog post? If so, email me: jed@privacyassociation.org
  • comment Peter Westerhof • Apr 18, 2014
    James has a point, although formulated a bit harsh. Stating 'you lawyers' is missing the point entirely.
    
    PbD, PET, etc. are around for quite a while now. And correct me if I'm wrond, but I can't see much progress.
    On the other hand issues regarding Governance&Compliance; relating to security - of which privacy is 'only' part - are increasing.
    
    I disagree that this is an engineering issue. It is an architecture issue first of all.
    Combined with the Governance&Compliance; aspects this makes for a major management subject at enterprise level.
    
    It seems difficult to get that on the agenda of the Board, short of having a Enron-scale crisis.
    As long as the management responsible is not held personally accountable nothing much will happen.
    
    And alas, this also is hardly news.
    Question is 'What are we going to do about it'.
  • comment Peter Brown • Apr 18, 2014
    I have an issue with the term "privacy engineering" - I think that we can engineer privacy-enhancing and data-protection technologies but engineer privacy? I really don't think so. Privacy (or lack thereof) is a social concept, heavily dependent on context as much as by personal choices and perceptions.
    I agree with Peter W. - Board and C-Suite concerns are not with the engineering but with outcomes, harms, risks, and benefits.
    Technical standards - such as the OASIS "Privacy Management Reference Model and Methodology" (disclosure: I am one of the editors) - do have their part and can help surface some of the technical agenda but, alone, engineering is not going to offer a solution
  • comment LaVonne Reimer • Apr 18, 2014
    I'm a lawyer-turned-entrepreneur who works very closely with her engineering teams. My interest and work has been in systems that deal with data of value in both their identified and de-identified state with obvious differences in level of sensitivity. I get why you all talk privacy this and that but wonder if the conversation and solutions might not work better if we thought of the challenge as data stewardship.
  • comment Karima • Apr 19, 2014
    Very candid, and valuable point. Where do you see the best place to begin introducing privacy principles into the engineering process?
    
  • comment Richard Beaumont • Apr 23, 2014
    I am neither a lawyer nor an engineer, but in many ways I make my living trying to bridge the gap between the two. James has some very valid points.
    
    As noted in the article, you can't code 'reasonable'.  The language of the law is necessarily grey, the language of code is not.  This is a major sticking point - we have seen the issues it has caused most recently with the EU cookie law, its different interpretations and difficulties with engineering 'compliance' with it.
    Ambiguities in the law are often it seems to me deliberately designed to avoid getting painted into a regulatory corner.  But those ambiguities are no good in engineering.  The web is where it is because of massive standardisation of the engineering at a globally agreed level, but it has taken years to even get where we are - even with a standard like HTML, we have to code for the quirks of different browsers.
    
    I almost agree with LaVonne when she talks about abandoning 'privacy' for 'data stewardship'.
    
    For Privacy Engineering to actually emerge as an engineering discipline, what we need to do is de-couple the 'privacy' bit from its various legal interpretations. And this also means embracing standards of privacy that are totally independent of all jurisdictional considerations, but can then be applied in specific circumstances to those different situations.
    
    In other words, and still simplistically we need to be able to write specifcation statements like 'We will apply level 1 privacy to all data as a minimum, level 2 to data types 3 and 4 under specific US requirements against law X, and level 3 to data types 5 and 6 based on the EU GDPR' - and every engineer reading that will know exactly what that means in terms of what has to be done.
    I don't think its impossible to do, but it will require the privacy community to become much more multi-disciplinary - which I think is already happening, and probably faster than many people realise.
    
  • comment Chad • Apr 24, 2014
    I tend to be the same camp as James (and ‘those engineers’ tend to be blunt like that).   We deal with ‘soft’ functional requirements in system design and non-function requirements in system architecture in software engineering, safety engineering, security engineering and human factors engineering and I don’t believe that privacy engineering is a very different case.   There was a very nice presentation at the conference on the Carnegie Melon Master program that demonstrated areas where engineering can be usefully applied, and I think there are huge opportunities to move forward in this area.   An item to keep in mind is that a system engineered to provide a variety of privacy functions (minimal collection, de-identification, data verification, preservation of confidentiality, etc.) will not provide or preserve privacy if it is not used appropriately, any more than a system designed to provide security will do so if used inappropriately.  As a result,  privacy engineers are unlikely to reduce the number of privacy attorneys we need.
  • comment Michael Aisenberg • Apr 25, 2014
    Personal View: As I cautioned (obliquely) during one of my comments at the Workshop, to seriously DISCUSS engineering Privacy is a noble endeavor, certainly worth the investment being made.  To seriously contemplate ENGINEERING Privacy within the operational environments present in U.S. and global infrastructures today in the absence of some well-anchored reference points in the Constitutional principles being addressed when we speak of Privacy and its associated civil liberties "stack" is to run the risk of turning back the clock in this area in a manner not unlike the one we are experiencing with civil rights and the franchise..The pervasive nature of the network and the facile use of it being made by disproportionately powerful economic and governmental interests (and the pseudo-seductive nature of their deployment of "social networks" and other artifacts/artifice as a means of lulling users into compliance) are all capable, even without any conspiracy,black helicopters or other overt plan to work to undermine the progress of individual liberties advanced (sometimes painfully) since the adoption of the Bill of Rights.  As Dr. Franklin forecast--a Republic-IF YOU CAN KEEP IT.