Re: RFC 6973: Privacy Considerations for Internet Protocols

Hi Frank, Hi Bob,

Just a minor remark on the confidentiality aspect:

In RFC 6973 we re-use the terminology from RFC 3552:
http://tools.ietf.org/html/rfc3552#section-2

"
2.1.1. Confidentiality

    When most people think of security, they think of CONFIDENTIALITY.
    Confidentiality means that your data is kept secret from unintended
    listeners.  Usually, these listeners are simply eavesdroppers.  When
    an adversary taps your phone, it poses a risk to your
    confidentiality.
"

The NIST SP 800-53 uses confidentiality in a much broader sense; it 
seems to include aspect that we cover under "Stored Data Compromise".

The confidentiality terminology in RFC 3552 has a fairly long history in 
the security community. The SP 800-53 terminology can probably be 
explained by the target audience for that document. Protocol designers 
are clearly not the audience for SP 800-53.

Ciao
Hannes

PS: Regarding the earlier remark about mandating a privacy consideration 
section. This document is work done by the Internet Architecture Board 
(IAB). The IAB cannot enforce such a mandatory inclusion of a privacy 
consideration section since the IAB is not the document approving body 
for the IETF document stream. It is as simple as that.

The IETF security area directors, for example, could publish a (short) 
document that requires privacy to be taken into account and that privacy 
considerations be documented. The available guidelines would help 
document authors to accomplish that goal. Rumours say that they are 
working on such a document...


On 08/08/2013 04:33 PM, Frank.Dawson@nokia.com wrote:
> *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
> *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 3^rd 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/*
>

Received on Thursday, 8 August 2013 16:39:14 UTC