Thursday, July 25, 2013

IETF RFC 6973: Privacy Considerations for Internet Protocols

This RFC was just published. It is to “Privacy” what our “Security Risk Assessment Handbook” (Cookbook) is to “Security Considerations”.
It thus intends to direct standards writers on how to determine if their standard has a Privacy impact, and how to mitigate those privacy impacts through modifications of their specification.

This is a very impressive and well written document. It does a good job of explaining the problem space, provides tools to use to determine the risks, provides tools to help with data minimization (de-identification), and very nice guidance on what a standard can do about privacy vs what must be handled later in a system or operational design.
  • Section 2 describes the extent to which the guidance offered here is applicable within the IETF and within the larger Internet community. 
  • Section 3 explains the terminology used in this document. 
  • Section 4 reviews typical communications architectures to understand at which points there may be privacy threats. 
  • Section 5 discusses threats to privacy as they apply to Internet protocols.
  • Section 6 outlines mitigations of those threats. 
  • Section 7 provides the guidelines for analyzing and documenting privacy considerations within IETF specifications.
  • Section 8 examines the privacy characteristics of an IETF protocol to demonstrate the use of the guidance framework.
I think the concepts on data minimization (de-identification) that they include might need to be harmonized with similar concepts within Healthcare. I don’t think the concepts are different, but they are described differently and thus a careful cross-reference is needed. I do like how they frame these tools in the context of the use of this, vs the use of de-identification in operational environments.

RFC-6973: Privacy Considerations for Internet Protocols
http://tools.ietf.org/html/rfc6973
[RFC3552] provides detailed guidance to protocol designers about both how to consider security as part of protocol design and how to inform readers of protocol specifications about security issues. This document intends to provide a similar set of guidelines for considering privacy in protocol design. 
Privacy is a complicated concept with a rich history that spans many disciplines. With regard to data, often it is a concept applied to "personal data", commonly defined as information relating to an identified or identifiable individual. Many sets of privacy principles and privacy design frameworks have been developed in different forums over the years. These include the Fair Information Practices [FIPs], a baseline set of privacy protections pertaining to the collection and use of personal data (often based on the principles established in [OECD], for example), and the Privacy by Design concept, which provides high-level privacy guidance for systems design (see [PbD] for one example). The guidance provided in this document is inspired by this prior work, but it aims to be more concrete, pointing protocol designers to specific engineering choices that can impact the privacy of the individuals that make use of Internet protocols.
Different people have radically different conceptions of what privacy means, both in general and as it relates to them personally [Westin]. Furthermore, privacy as a legal concept is understood differently in different jurisdictions. The guidance provided in this document is generic and can be used to inform the design of any protocol to be used anywhere in the world, without reference to specific legal frameworks.
Whether any individual document warrants a specific privacy considerations section will depend on the document's content. Documents whose entire focus is privacy may not merit a separate section (for example, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks" [RFC3325]). For certain specifications, privacy considerations are a subset of security considerations and can be discussed explicitly in the security considerations section. Some documents will not require discussion of privacy considerations (for example, "Definition of the Opus Audio Codec" [RFC6716]). The guidance provided here can and should be used to assess the privacy considerations of protocol, architectural, and operational specifications and to decide whether those considerations are to be documented in a stand-alone section, within the security considerations section, or throughout the document. The guidance provided here is meant to help the thought process of privacy analysis; it does not provide specific directions for how to write a privacy considerations section.

Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

1 comment:

Sunday, July 21, 2013

getting to mHealth solutions - real People


I started this with explaining "how" mHealth solutions should authenticate their users. Hint, it is through oAuth and more so through Internet friendly authentication service providers such as Google, Facebook, LinkedIn, Twitter, Yahoo, or others. I recommend this solution as it abstracts out the hard work of user management, password management, multi-factor authentication, password resets, etc. These are not value-add functionality of your mHealth application, so might as well pick a good pluggable standard and outsource. It doesn't however absolve you of responsibilities. You still must choose wisely which of these Identity Providers you are going to allow your users to use. You also do still have power and responsibility, in that if an Identity Provider that you allowed becomes 'bad', you can revoke those access credentials. So you still have power and responsibility; yet you can outsource much of the hard work.

The problem is that these Identity Providers don't tell you who the user actually is, most of the time they have no clue. You are not even sure that the individual isn't a dog. These accounts are created by the user for the user. The only thing these accounts can tell you is that it is the same individual, at least within the control of that user.  For most social networking uses on the Internet this is a fine restriction, as in those cases the user creates content that everyone sees simply as coming from whoever.

So, how do you know which real person this account belongs to?

The social networking sites do actually have this problem, just not in the same way. There is a need in social networking to have 'Verified' accounts. (Twitter Verified Account) This is typically because the user account name is a representation of a 'star' or someone of 'influence'. Most of the time it is because the account name is a Trademark. So some of these Identity Providers have means where they will allow a user to dispute a different user holding a account name that could be 'confusing to the public'. This is nice, but not sufficient.

Identity Proofing - Level of Assurance

I have covered Level Of Assurance, I am not going to cover them again.
I will however indicate that to access Health Information, as the Patient or as a Provider treating the patient, one does need a HIGH assurance. This might be Level 4 or might be a modified Level 3. What is important is that one must be very sure that the HUMAN is indeed the human you intended.

Specifically it is the Identity Proofing - Level of Assurance - that I am going to work on next. That is how sure are we that the identity given is the specific individual. This is different from 'session-authentication-strength, meaning how sure are we that this individual is the same one that the identity was issued to. We are actually outsourcing the session-authentication-strength to our oAuth Identity Provider. Remember, outsourced but not out-of-control.

So the problem we have with the solution we have chosen is that the Identity Provider doesn't give us any claims that the identity belongs to a specific individual They are really just saying that it is the same individual each time (session-authentication-strength). So we have NOTHING to base the Identity Proofing - Level of Assurance. How can we possibly use these Identity Providers for Healthcare?

Post Identity Proofing

We bind the human identity to the technical identity, after the fact. This is backward from corporation based identities. In a company one gets issued a user identity after you start work. HR has already vetted you, and you have received some form of training. In a work setting the Identity Proofing is done before an Identity is issued. In the case I am explaining we do that Identity Proofing later, delayed not forgotten.

You are already use to a form of this. When you signed up for Facebook, they sent you an email that you had to click-on a link to prove that you had access to that e-mail account. This is what Facebook sees as "Account Verification". It only proves that you have access to a different account, thus Facebook can bind those two identities into a 'greater' identity. This isn't really verified, but it is a step they take.

Binding Identities

Many Healthcare Providers already use a system that I think would work well here for their Patient Portals, although I modify the process slightly as I don't want the mHealth application to manage authentication. The solution uses the USA Postal Mail. Testimony was given last year to the HIT Policy committee

The healthcare provider already knows the patient, they have in-person-proofed them, and created a Patient Identity. They have likely already billed and received payment from the individual. This by any standard is considered one of the highest forms of Identity Proofing - Level-Of-Assurance. Again it might be a Level 4 or a modified Level 3 if you get picky about the use of a Federally Issued Identity.

So what needs to be done is somehow the highly Identity Proofed Patient ID needs to be bound to the non-Identity Proofed oAuth identity, and this needs to be done in a verifiable way that can be trusted and proved trustworthy. So, send the patient a letter with a shared secret string, a one-time-passcode. Tell the user to login to your Patient Portal with whatever Identity Provider they choose (the choice I gave in the first article). Once logged in, your Patient Portal will notice that the user account is not yet bound to a Patient Identity so you will prompt the user for this one-time-passcode that you mailed to them. Once they enter this code, you know that the individual is indeed the same individual. You can now consider these two identities bound by this relationship of patient-as-a-user to patient-as-a-health-record. You have the assurances of the USA Postal fraud laws that the mail was only opened by the one it was addressed to. It really doesn't matter if that individual 'outsourced' the computer interactions to their geek-daughter (or geek-granddaughter).

I show you how to do this with a Patient accessing mHealth which is a Patient Portal. I leave as an exercise to the reader how to deal with mobile applications, and how to deal with Providers using internet identities.

Bi-Directional Bound Identity

At this point I suggest we are not done. This Internet Identity that the user is using is bound to their Healthcare Identity, but is their Healthcare Identity now bound to their Internet Identity? Should it be? This is a good case of needing to get informed consent, but I might indicate that binding the identity both directions is desireable. The user account that the individual chose is by-their-choice. If they are willing to, they should be able to be known by that Internet Identity. Meaning the Internet Identity used as their username, can become their Voluntary Patient Identity. This can help with the HIE Patient Identity Problem, and a good HIE identity enables better Privacy controls. See also: Patient Identity Matching

Next up: real Access Controls

This leads me to the next subject of: How to do more complex access controls? It isn't obvious yet, but with oAuth your mHealth application is not enabled to do Role-Based-Access-Control or Patient-Privacy-Consents-Authorizations. All you get with out-of-the-box oAuth is an opaque token to represent the individual.
No comments:

Friday, July 19, 2013

getting to mHealth solutions - Users

How do we 'get to' mHealth solutions?

What is mHealth? It is clearly almost anything you want it to be. For this article I will consider mHealth the ability to access Health Information on mobile devices. This might be a health professional treating a patient, or this might be the patient accessing their own data. In both of these use-cases one has highly sensitive health information and some authorized access. The biggest difference here is the Access Control Policy, I will show that treating this as a policy allows the technology to mature at different rates.

I am going to break it down in the following way. It is not the only way to deconstruct, but it works for the topics of Privacy, Security, and enabling technology.

a) How to authenticate users?
b) How to know who that user is?
c) How to do more complex access controls?
d) How to eliminate patient identity cross-referencing errors?
e) How to enable application developers to develop one application regardless of where the data is held?

Inside of this deconstruction I will speak about multiple aspects of Identity, Level of Assurance, Authorization, Consent, and Trust. These are different ways to deconstruct, but they are harder to explain the solution I will explain. They are going to get covered, just not as components of the outline.

First, Please use good design that includes Privacy and Security from the beginning. Bolting these concepts on later just doesn't work. That doesn't mean that these can't be modularized or architected as-a-service. In fact by defining functionality as services one gets great architecture that gives great flexibility. This is indeed included below. For basic security and privacy I recommend NIST. 

a) How to authenticate users?

Please do NOT create your own password database or user authentication scheme. Please treat the process of authenticating users as a service. You can implement that service your-self, and likely do need to do so for some of your users. By treating user authentication as a service you enable the user to have some choice. You enable combinations of services to work together, mashups. You abstract out the authentication technology so that it can be enhanced and strengthened as needed.

If you are creating applications by an organization for that organization, then SAML is the most likely solution. I am not going to cover SAML much here, but that isn't because it isn't the right solution sometimes. However SAML is best for organizations that want to enable identity federation (portability) while still holding control of those identities. When a new application needs identities then the SAML authority must be told about it. Thus the authorization of a new application is controlled by the SAML identity provider. This works well for businesses, as businesses tend to need business-agreements to be in place before applications really are allowed to do something.

If you  are creating applications for consumers, then oAuth is the most likely solution. Again, SAML might be, but might not. Both oAuth and SAML are technically very similar, as they are also technically similar to Kerberos and PKI. The differences between each of these is important and deliberate. What oAuth brings to a consumer marketspace is that the user is the one that controls authorizing a new application. This tips the administrative process around from SAML. In oAuth the user is given the choice of what authentication provider to use, the user is given the control to authorize an application, and also to remove authorization from that application. This is a very powerful concept. This is the "Authorization" that is part of oAuth, not to be confused with Role-Based-Access-Control or Privacy-Consents-and-Authorizations. These are related by not the same thing. 

The user experience is best to explain. With oAuth, the user gets to choose what identity provider they will use (within some constraints described later). Typically when they first go to a web site that needs authentication, such as a social media or blog, they will be given the choice of identity providers to choose from. Choices like Google, Facebook, LinkedIn, Twitter, MySpace, Yahoo, or even SalesForce.com. When the user clicks on one of these, the web page 'from that site' is asked to authenticate the user and authorize the application you have. That Identity Provider does what ever it needs to to authenticate the user, this allows that site to use 2-factor authentication if it does that. This allows the Identity Provider to change authentication systems. Thus when a new authentication systems comes about the Identity Provider changes, not your application. Example is this year using a cellular phone SMS message became really popular as a second factor authentication, this is transparently added by for example Google authentication.

The user is asked if they want to Authorize the application that they just came from. They are given some information that your application provided. If they agree to Authorize your application, then you get a 'token' that can be used in various ways. If they don't agree then your application gets nothing. Really cool part is that the user can go back to their Identity Provider at anytime and REMOVE that Authorization. This is the Authorization that oAuth manages. This is not the same as Role-Based-Access-Control or Privacy-Consent-Authorization. I could see oAuth enabling these, but it isn't these.

At this point you have used out-of-the-box oAuth. You have not needed anything special for healthcare. But you don't know who the user actually is. You just know that each time this user comes to your application it will be verified by their Identity Provider as the same individual. This is good enough for most social networking or self-created content (blogs). All that these applications need to do is make sure that the same user comes back, and that others that are not that user can't get improper access. Thus simple oAuth can separate the 'same user' from 'everyone else'.

next up:
b) How to know who that user is?
c) How to do more complex access controls?
d) How to eliminate patient identity cross-referencing errors?
e) How to enable application developers to develop one application regardless of where the data is held?

For references see: My Topics page

User Identity and Authentication

No comments:

Wednesday, July 3, 2013

NIST Releases Draft Outline of Cybersecurity Framework for Critical Infrastructure

I like what NIST does regarding Security guidance. I know that they are a USA government body, thus those outside the USA have some reservation. I however find that they hit all the right buttons on their Security specifications. They are catching up a bit on their understanding of Privacy.

I have high hopes, but not too high, for their new Cybersecurity Framework. First, I am dissapointed that NIST would be dragged into a buzzword and forced to say "cybersecurity" as if it is a term that everyone knows totally. But, sometimes one must do the buzzword bingo
As part of its efforts to develop a voluntary framework to improve cybersecurity in the nation's critical infrastructure, the National Institute of Standards and Technology (NIST) has posted a draft outline of the document to invite public review and gather comments.
The Executive Order calling for NIST to develop the framework directs the agency to collaborate with the public and private sectors. The draft outline reflects input received in response to a February 2013 Request for Information, discussions at two workshops and other forms of stakeholder engagement.
 The framework so far is useless, but their approach is good. It will be Risk based, and leverage existing standards. This is music to my ears.
The draft outline and other documents related to the Cybersecurity Framework are available at http://www.nist.gov/itl/cyberframework.cfm.
The most informative part of this announcement is their presentations:
No comments:
Subscribe to: Posts (Atom)