Friday, October 5, 2012

Preventing the HIE Cloud from Raining Data

The HIE of yesterday was based on legacy connections across private networks (VPN mostly). Access may have been over the Internet with just a user ID and a password. While this seems little security, it is generally pretty good so long as your password policy is strong and your users understand the basics of passwords (no sticky notes on the monitor).

That type of HIE had a centralized security model. Now, I welcome you to the modern HIE, connected by either web services and secure email. This decentralized or federated security model is not something healthcare is used to dealing with. There are two major issues that need to be addressed:
  1. What is the security policy of the system that actually authenticated the user
  2. Is the system that authenticated the user, actually the system I think it is.
Suppose you have users connected via web services for cross domain data sharing (XDS) by which they can pull clinical data into their system or viewer. Or suppose you just have single signon (SSO) solution that allows a trusted connection to establish a session for a user. Or even if you have QueryHealth with a query and response over Direct in the future. Our first question should be, "What is the security policy of the system that actually authenticated the user?" If we have a policy for strong password, limit password reuse, two factor authentication, disable accounts after a number of attempts, maximum session time length, etc. shouldn't this client system to the HIE have to have the same policy or stronger? Yes it should, so these, if not expressed during connection in SAML, should be established by policy with all HIE participants.

Now suppose those web service connections rely on public key infrastructure (usually for SSL client authentication, encryption, and digital signatures). Or, suppose you do HIE via Direct (S/MIME protected email). The private key needs to be kept private. If the wrong person obtains private keys, then public key security is defeated. That person can impersonate the authorized owner of the private key. If the private key is a credential for a hosted EMR, the person can impersonate any of the users that that EMR vendor uses that key for during authentication. So our next questions should be, "What has been and will be the custody and protection of the private key?" and "What happens if you find out a key is compromised?" Then we need to evaluate those answers against our policies to see if we really want to connect to such a system.

From the other side of the equation, we should be asking ourselves, can I detect use of a stolen certificate even though the certificate owner does not know it has been stolen? Are we mapping IPs to certificates and participants? Do we have an XML Firewall (e.g. IBM Datapower or Level 7) in front of our XDS web services? Are we monitoring for unusual shifts in the use of these credentials using event monitoring for fraud detection? If not, maybe we should. Otherwise, maybe the VPN was better.

For password access, one of the most common techniques for 30 years has been to tell a user when they last signed on and from where. That way, if their account was compromised, they know it and can contact a system admin. This closes the loop. For certificates, maybe we should close the loop on federated security by reporting accesses back to the source system provider and they should match to authenticated user activity to find if the certificate was used by another system. This is of course a use case for query of the ATNA repository by the accessing system. However, the reality is that few if any client systems are prepared to close this loop by using query of ATNA.

The above sounds like a bunch of stuff the techies work out and nobody needs to worry about it. However, most of the above is policy not technology. We need to require policies for those we connect. Our password policy or stronger needs to be their password policy. Their certificate management policy needs to be acceptable under our policy. Those we connect to, to pull data from, should have similar policies to place requirements on us. In the end, even if your hospital or practice connects to the HIE via legacy connections and portals, you are still concerned. This is because it is the other guy, and how he is connected, that exposes your data. While I believe today's HIEs are secure, they rely too much on everyone to "do the right thing" without a policy or contractual agreement telling them what that is. So, I am advocating that we need to federate the security policies as we federate the authentication of the user. And we are federating the authentication of the user, because that is what lets them stay in the workflow of one system. So in the end, if we want access to patient data embedded in the workflow, we need to make sure we have good federated security policy.

11 comments:

  1. In a public HIE using IHE orchestration (see http://bit.ly/UJjmE2), in addition to application layer security (VPN, SSL), a combination of payload encryption and the use of SAML can be used. I agree with you that certificate management has to be very robust to ensure privacy and security. The good news is that IaaS and PaaS solutions now offer robust identify federation that can address this problem.

    ReplyDelete
    Replies
    1. Agreed. My concerns actually extend into those service providers. I'm not concerned about the technology that we have in place so much as the policy to assure everyone is compliant.

      Delete
  2. Seems to me a federal health IT solution is needed to support HIE security over state based. How will this be affected by a Romney health solution that is against federal health care mandates (I assume federal HIT mandates as well)?

    ReplyDelete
  3. To be sustainable, health information exchanges must be relevant as well as secure. Here's my post to the Healthcare Working Group IDESG (NSTIC) on the relevancy of DirectTrust.org: http://goo.gl/7Bg6L

    ReplyDelete
  4. Our novel point-to-point/peer-to-peer DIRECT implementation adds end-to-end encryption to the PKI requirement. It doesn't require a "HISP in the cloud" since a desktop email client STA (MS Outlook), together with an RA/CA to handle the certificate management processes, provide all necessary HISP functions. This model addresses many of the concerns presented.

    ReplyDelete
    Replies
    1. Direct or Repository, certainly everyone does end-to-end encryption. But what policies do you have in place with the RA and CA? Who there has access to the private key of the certificate? What happens when one of them is terminated? What policy does the endpoint (EMR I assume) have for password or other protections to ensure that the user sending with that private key is the person assigned the certificate? Can the EMR vendor tech support ghost an account and pretend they are any user? My post is about policy not technology. The technology is secure, but policy current relies too much on the honor system.

      If someone wouldn't let someone else into their system without having a user account with password controls that you setup, why would they be so comfortable with their trading partner authenticating users for them and not knowing what controls they have in place? Maybe they haven't changed their password in 20 years and it is set to their spouses name and a lot of people know it.

      Last, what happens when Direct expands into QueryHealth? Now those credential issues query your system.

      Delete
  5. More cloud companies are developing new business-targeted services in an effort to reach these enterprises. Service providers are simplifying the process of implementing online backup, creating cost efficient offers that enable even smaller businesses to take part, and developing flexible plans that cater to specific needs or restrictions within a certain company or situation.
    vdr secure file sharing

    ReplyDelete
  6. In coming years, cloud computing is going to rule the world. The cloud based CRM tool provider like Salesforce have massive demand in the market. Thus talking Cloud Computing Training in Chennai from reputed Cloud Computing Courses will ensure bright career prospects for aspiring professionals.

    ReplyDelete
  7. Thank you for Sharing. I'm working in brave technologies private limited, We are the best erp software developers based in chennai. erp providers in chennai

    ReplyDelete
  8. I heve read your blog it's very interesting and informative. Keep sharing.
    erp in chennai | erp software solutions in chennai

    ReplyDelete