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.