RE: RFC 6973: Privacy Considerations for Internet Protocols

Hi Frank,

Sounds good to me.

Avanti,
BobN

From: Frank.Dawson@nokia.com [mailto:Frank.Dawson@nokia.com]
Sent: Thursday, August 08, 2013 10:33 AM
To: Natale, Bob
Cc: public-privacy@w3.org
Subject: RE: RFC 6973: Privacy Considerations for Internet Protocols

Hei Bob.

I am suggesting separation of control catalogs, not necessarily the separation of privacy and security assessment. Indeed, project teams have limited resources and time and for example in Agile Teams, the daily SCRUM meetings or weekly SPRINT planning sessions have found that combining security, privacy and business continuity requirements review is an efficient way to integrate PbD into their way-of-working.

So, just to summarize, my point was that privacy control catalogues should to be minimally structured as tuples of:

Reference ID, Privacy Principle, Threat, Control

I prefer the expanded tuples of:

Reference ID, Privacy Principle, Privacy Data Lifecycle Step, Threat, Control

The privacy principles may make use of a term that is also used in infosec but the semantics will be that of information privacy (infopriv).

Frank/

From: ext Natale, Bob [mailto:RNATALE@mitre.org]
Sent: 07 August, 2013 22:35
To: Dawson Frank (Nokia-CIC/Dallas)
Cc: public-privacy@w3.org<mailto:public-privacy@w3.org>
Subject: RE: RFC 6973: Privacy Considerations for Internet Protocols

Hi Frank,

Here is the definition of Confidentiality used in SP800-53:

"Confidentiality

[44 U.S.C., Sec. 3542]

Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information."



I have a hard time not interpreting "including the means for protecting personal privacy" as both what we commonly mean by "privacy controls" and also circular with your inclusion of "loss of confidentiality" in your definition of privacy below.

Furthermore, I do not share your enthusiasm for separating these concepts - or, more importantly, their instantiations in practice and operations - as the mad rush to hyper-fractionalization of such closely interrelated concerns (in the real world of individuals and organizations) has led to unsustainable costs and reduced overall effectiveness ... IMHO, at least.

Avanti,
BobN

From: Frank.Dawson@nokia.com<mailto:Frank.Dawson@nokia.com> [mailto:Frank.Dawson@nokia.com]
Sent: Wednesday, August 07, 2013 6:10 PM
To: Natale, Bob; joe@cdt.org<mailto:joe@cdt.org>
Cc: public-privacy@w3.org<mailto:public-privacy@w3.org>
Subject: RE: RFC 6973: Privacy Considerations for Internet Protocols

Hei Bob

<snip/>

All good points, but I especially support your 3rd bullet ... on making Privacy Considerations coverage mandatory ... and would prefer the combined option ("Security and Privacy Considerations") to promote consolidation (where appropriate) of the Confidentiality leg of the security controls "CIA" triad with closely associated Privacy controls.  (This is something that, in my judgment, the recent and otherwise excellent rev 4 update of NIST's SP 800-53 (now with "Security and Privacy Controls" in the title did not get as right as it could have, since the Privacy controls are in a separate Appendix J).

I am okay with privacy controls in the NIST SP being in a separate annex. They should be separate. Privacy controls are safeguarding privacy requirements based on privacy principles. Security controls are safeguarding infosec requirements based on CIA, STRIDE or whatever infosec ISMS you are following. Risk in privacy is about harm to the individual natural person, whereas risk in security is about harm to the owner of the computer and digital assets. Even the risks are different.

E.G.,

Security: Unauthorized access threat could lead to data theft risk

Privacy: Unauthorized access threat could lead to identity theft or misrepresentation or loss of confidentiality

Some parties what to take a Information Security Management System like ISO 27001 and use it like a hammer because they see the world as a bunch of nails. Privacy requires its own Privacy Management System. I am okay if it is fashioned after ISO's 27001, ISF's SGOP or COBIT or another ISMS framework, but it needs to be repurposed for privacy which may mean changing its processes and activities.

On the matter of NIST SP 800-53 Appendix J, I would like to see a lower level set of controls that are more technical and relate to web and internet apps and services, maybe looking at what OWASP has done.

Frank/