Wednesday, December 16, 2009

Federated ID is not a universal ID

I run into people who miss-understand Federated ID as requiring everyone to change to a universally issued user identity with universally issued roles. This is absolutely not true. Let me lay some ground work then bring them together.

For the most part I don’t think that user identity is important in cross-enterprise transactions like EHR requests into an HIE. Not because they are a bad idea, or that they are not good security; but rather because most of the usecases that we are looking at, and the interactions that are being executed are system-to-system or organization-to-organization. In this mode the two systems (or organizations) need to trust that the other system has done the appropriate pre-conditions and will do the appropriate post-conditions. This is Policy and Procedure: Don’t let a system connect that you don’t trust has the appropriate governance. What this means is that the client machine has done appropriate user authentication, authorization, and is otherwise a secure system. The communications is highly authenticated (TLS) on both client and server. The result returned back to the client will be properly handled, exposed only to authorized individuals, and the maintain audit logs of all accesses from that point forward. If we add a user identity to this transaction, it is mostly for a little bit better audit log on the service side.

The other side of this is that even if a user identity was provided it would be about the user that is right-now connecting. If this is a request from a clinical system (e.g. EHR) the result will be stored and others on the clinical system will gain access. So although the initial connection could be access controlled, the other future accesses within the EHR must be trusted to do the right thing. I worry that people see the user assertion and end up with a false sense that all accesses are singular accesses back to the original system. Thus there is a false sense of security, rather than a healthy-suspicion that doesn’t let the whole-system connect at all until the downstream workflows are checked out too. There are other transactional complexities that simply adding an assertion doesn’t help. But there are also applications other than an EHR that can operate on single-read-only-use (more on this later in this post)..

If we look at an EHR today, it has user authentication and access controls that have been built up over time to meet the requirements of being an EHR. The user authentication likely is highly flexible to support some rather strange workflows. One of the strange workflows is the exam room, where an administrative person walks the patient to an exam room and sets up the exam-room-terminal with the right patient then ‘locks the screen’. Next the nurse comes in to take complaints and vitals logs in, enters them, and logs out. Next the doctor comes in for the exam, again logs in to enter data and logs out. Each of these people are authenticating, but the workflow on the desktop is all about the patient. These authentication methods and authorization methods are sufficient to protect the PHI that is maintained inside that EHR. It is possible that an organization has gone to an enterprise class authentication system like Active Directory or more generically Kerberos or LDAP, but this is not required.

Lets look at interacting with an HIE or other organization that requires a SAML assertion. A SAML assertion is issued by an Identity Provider that supports SAML. This Identity Provider is configured to understand specific targets of the SAML assertions (known in SAML terms as an ‘audience’). The configuration will include mapping tables that indicate that when creating a SAML assertion for use within a specific HIE that some list of attributes need to be added to the assertion. One likely attribute is the HIE-role values which is assigned based on the Role or attributes within the Identity Provider. Thus if I am known as a Physician in my local LDAP Directory, but the HIE wants the role to come from a different valueSet where my role within the HIE would be “Care Giver” then it is up to the Identity Provider to do this mapping. This is a common thing for Identity Providers to do, as role vocabulary is not stable within any organization (not just healthcare) nor is it likely to be stable inside the HIE. What is important to recognize is that the SAML assertion is issued by an Identity Provider that does this mapping. The native user directory does not need to have the HIE-roles. When this SAML assertion is received by the Service Provider it is validated which checks that it was issued by an identity provider that is on the trusted-identity-provider-list. This allows the Service Provider to support many different Identity Providers, likely one for each clinic and hospital connecting to the HIE. Given that all of those identity providers have normalized their roles to the HIE-role vocabulary it is clear what permissions the user should have in the context of this transaction in the HIE.

I now bring together these two ideas. Given that the EHR has a mature user authentication and authorization system that is likely highly customized to the clinical workflows it is not likely that system can be replaced. The good news is that this is a mature system. So, one first step is to have the EHR be the Identity Provider. It is simply XML with a digital signature. Yes, the HIE better do proper checkout of this Identity Provider, but after this happens the HIE would trust it. I wrote up in a white paper for IHE on this topic in 2005: “XUA Implementation Demo 2005 Guide.doc” .

This may work long-term, but likely enterprises will choose to go to an enterprise class user-authentication system to gain all of the advantages of single-sign-on and much quicker user provisioning and de-provisioning. But once this transition is done, then that enterprise class user-authentication system should be specified as a cross-enterprise class user-authentication system. The WS-Trust protocol would then be used to get SAML assertions issued.

Now is when I must add the exception to the rule. The above discussion was around clinical access to an HIE by an EHR. I think this is the most important HIE access and the one that brings the biggest benefit while being most simple. I think the same can be said about a PHR, although I have less sympathy for a PHR as they are generally less constrained on workflows (exam room) and are also rather newly designed. So a PHR could more easily provide user assertions, still I am not sure why that assertion is specifically useful. But there are other parties that are being connected to the HIE. I think these other parties may be more likely candidates for getting benefit from requiring assertions….

Monday, December 14, 2009

Observation on REST vs SOAP

Last week was especially frustrating. The technical topic of the week was REST vs SOAP, but what was not obvious to most observers is a frustration that has NOTHING to do with REST vs SOAP. You might be seeing this frustration on the faces, the emails, the voices, and the blogs of those of us who spend a majority of our time participating in OPEN and CONSENSUS processes. We place ourselves on the mercy and critique of others multiple times a day. Everything we do is included in openly published minutes, draft documents, ballots, ballot-comments and such. Our names are well known, our addresses and phone numbers are well known.

Along comes this nameless and faceless "community" that somehow gains power by coming to the party late and simply having an advocate appointed to a high office. These people are not involved in the many years it has taken to develop the standards. These people can not be communicated with. Their ideas are taken without question. We have no idea who they are. Even Vinton Cerf and Aneesh Chopra are names without any way to have a discussion with. I applaud John Halamka, even poking fun at/with him. I applaud John because he is approachable and forward. It is very hard to have the same respect for others that don't participate but simply throw FUD into the process late in the game.

Most of the discussion around REST vs SOAP has been this faceless "community" complaining that the HITSP selected standards for communicating clinical documents (XDS/XDR) is SOAP based. We hear that they want a RESTful equivalent. The first problem is to find a RESTful "standard" or "profile" that has been built in an open and consensus process. This specification is not just going to drop out of thin air. A highly important point is to make sure we have the requirements clearly identified. The Open and Consensus process is good for uncovering all of the requirements and making sure they are satisfied before we start to have hundreds of developers building products and networks based on that specification.

This is very different than what OHT and FHA-CONNECT have done by publishing a RESTful interface to these tools that speak using the HITSP selected standards on the backend. This kind of a RESTful interface is local and doesn't impact anyone outside of the local (which can be large) developers. I would really like to be sure that the existing specification is truly not sufficient before we create-new specifications that we then call parsimonious.

Friday, December 11, 2009

Double Standard?

I find it strange that John Halamka is willing to spend top-dollar for a Gortex suit because it has long term benefits that he sees will payout over time, while in the same blog telling the whole healthcare community that they should settle for a low grade solution even when that solution is known to be deficient in security,  determinism, versioning, reliability, flexibility, etc.

There have been many attacks on XDS/XDR as being overly complex including that they are SOAP based. These have also included questions of if HITSP should offer an alternative transaction that is RESTful.

The requirements that XDS/XDR satisfy are well documented in the IHE Technical Framework. I will highlight a few that are relevant to why the benefits of the SOAP stack are important:
  1. User Authentication supported by HTTP alone is inadequate for healthcare information. WS-Security includes support for many user authentication methods including Federated ID using SAML Assertions.
  2. URL representations of healthcare resources (e.g., Medical Record, Patient Chart, or provider ID, et cetera), can:
    • Expose PHI in web URLs (probably the most common security error made in web-based healthcare apps)
    • Create easily exploitable web pages (another very common security error). 
  3. Formal interface definition language in WSDL.  
  4. Support for end-to-end security while leveraging a flexible WS-Addressing and built in asynchronous support.
Although all of these are enabled by the SOAP stack, they are not mandatory and the minimal stack is profiled for XDS/XDR. The point is that adding the additional support from the SOAP stack is as simple as adding building blocks, where as one would need to code this into the application with a RESTful approach. Further point that is often lost in these discussions is that REST is an architecture, there is no standards that define REST. Where as SOAP is a standards based protocol.

We either clothe Healthcare in a ‘simple’ jumpsuit, or we build a long-term HIE architecture out of strong durable fabric.

Wednesday, December 9, 2009

Current Security and Privacy developments

This is a simple listing of all of the Security and/or Privacy developments underway. I am sure there is something missing, but I find it useful to track the efforts. This is grouped but not in any particular order. Please feel free to comment with updates. Getting access to the working drafts is not always possible given the governance of the controlling organization. I can assist with getting anyone engaged with the work item.
  • Country Specific
  • Profiling Organizations
    • IHE --
      • Update to XUA to add one or more options for attributes to enable Access Control. Potentially using XSPA, as well as experience from NHIN and epSOS.
  • Standards Organizations
    • HL7 --
      • Security TC
        • Security Domain Analysis Model
          • This project is intended to create and ballot a single HL7 Domain Analysis Model (DAM) integrating both security access control and privacy information models.
        • Risk Assessment Framework Cookbook
          • The scope of this project is to create a unified method and process to identify issues, categorize them using a standard and accepted risk framework, bring the risks to the attention of the Security Technical Committee (TC) and use the consulting and oversight of that committee to standardize the much needed solutions and at the same time leverage the limited resources available.
        • Privacy and Authorization Terminology
          • The scope of this project includes incorporation of additional RBAC permission vocabulary (e.g., Healthcare Financial Transactions), Privacy Consents and Constraints. Has passed ballot, now being reconciled.
      • CBCC TC
        • Update V3 Privacy Message
          • CBBC balloted a V3 Privacy message a couple of years ago that resulted in a normative standard; they may update this in the Spring of 2010.
        • Consent Directive CDA Implementation Guide.
          • The project is intended to produce a structured document specification to exchange signed Consent Directives.
        • Composite Privacy Consent Directive R2
          • In addition to the analysis of new requirements, this project will correct any problems detected in the current 'Data Consent R1' standard.
      • Joint work
        • confidentialityCode - clarification of the purpose of this attribute and the purpose of each vocabulary value. Hopefully this will NOT create unnecessary interoperability problems given legacy, IHE, and DICOM use of the same named attribute.
      • SOA - PASS
      • CCOW
        • SAML Assertions as proper user identity subjects
    • DICOM - (follow link for DICOM Standard) or (changes with annual publication)
      • DICOM supplement 95 -- Audit Trail Messages
        • fixes, radiology extensions, and addition of SYSLOG-PROTOCOL family
      • DICOM Supplement 142 -- Clinical Trial De-identification Profiles
      • CP-884 - DNS self-discovery for secure DICOM services
      • CP-892 - Add De-identifying Equipment to Contributing Equipment Sequence
      • CP-895 - Password based encryption for media security
    • ISO - TC 215
      • ISO/PRF TS 21547 Health informatics -- Security requirements for archiving of electronic health records -- Principles
      • ISO/PRF TR 21548 Health informatics -- Security requirements for archiving of electronic health records -- Guidelines
      • ISO/CD 22857 Health informatics -- Guidelines on data protection to facilitate trans-border flows of personal health information
      • ISO/CD 27789 - Health informatics -- Audit trails for electronic health records
        • Started based on RFC3881, but has diverged
    • IEC
      • IEC 80001 -- Risk Management approach to connecting a medical device to a healthcare network, including security risks.
    • OASIS --
  • Other Organizations
    • Joint working group HIMSS & NEMA
      • Next generation of MDS2

Monday, December 7, 2009

RHIO: 100,000 Give Consent

This RHIO is not based on XDS or BPPC, but the fact that they operate with a only an OPT-IN policy seems to validate that this approach should satisfy the 80/20 rule. I think that BPPC can and should be used to enable OPT-IN in an XDS like RHIO (HIE). This is not to say that BPPC is the long term solution, but rather that without a OPT-IN ability we will get nowhere on deploying the Health Internet. BPPC is 'good enough', and is a logical path toward something more advanced. HL7 is already working on that more advanced solution, and it is a logical extension to where BPPC is today.
The Rochester RHIO in New York has announced that more than 100,000 patients have consented to their physicians viewing their health information via the RHIO. Rochester RHIO started a pilot in 2007 with five practices and 27 physicians. Today, it serves more than 1,500 authorized providers including 500 physicians. Data exchanged via the RHIO includes lab reports, radiology images and reports, medication histories, and hospital discharge summaries. By January, the service will include emergency medical treatment data and information on health and human services for senior citizens. More

Wednesday, December 2, 2009

Web-Services RESTful vs SOAP

This isn't exactly Security or Privacy related but has been politically a hot potato that I must participate in because I am co-chair of the Security, Privacy and Infrastructure Workgroup of HITSP. The good news is that HITSP is getting a chance to deal with this formally in response to the "Common Data Transport" work item. This item first came to HITSP back when SOAP was king and no one had even heard of RESTful. Well the winds have changed and now RESTful is king and SOAP is a 'four letter word'. So I penned the following section for HITSP, much of the material does come from Wikipedia, but the text did jive with other resources I used.

3.1 Web Services

A web service is traditionally defined by the W3C as "a software system designed to support interoperable machine-to-machine interaction over a network. In common usage the term refers to clients and servers that communicate over the HyperText Transfer Protocol (HTTP) protocol. Such services tend to fall into one of two camps: SOAP Web Services and RESTful Web Services.

SOAP Web Services use Extensible Markup Language (XML) messages that follow the Simple Object Access Protocol (SOAP) standard and have been popular with traditional enterprise. In such systems, there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a web service.

More recently, REpresentational State Transfer (RESTful) web services have been regaining popularity. RESTful Web Services leverage more completely the HTTP protocol including: negotiations for media types, caching, authentication, and the HTTP methods as the verbs: PUT (replace or update), GET (list or retrieve), POST (create), and DELETE (delete). Unlike SOAP-based web services, there is no "official" standard for RESTful web service. This is because REST is an architecture, unlike SOAP, which is a protocol. Even though REST is not a standard, a RESTful implementation such as the Web can use standards like HTTP, URL, XML, GIF, etc.

Web API is a development in web services (in a movement called Web 2.0) where emphasis has been moving away from Simple Object Access Protocol (SOAP) based services towards more direct Representational State Transfer (REST) style communications. Web APIs allow the combination of multiple web services into new applications known as mashups. When used in the context of web development, web API is typically a defined set of HyperText Transfer Protocol (HTTP) request messages along with a definition of the structure of response messages, usually expressed in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format.

3.1.1 Selecting Web-Services

SOAP Web Services and RESTful Web Services are both very useful tools that have advantages and disadvantages. When defining a concrete implementation of a service it is important to pick the best tool for the specific job. The Common Data Transport Technical Note outlines some of these attributes that a transport may need to have. Not all of these attributes are always needed, so it is important to use the most simple tool that can get the job done.

Where the advantages of SOAP are necessary to meet the transaction requirements then a SOAP Web Service will need to be chosen.

RESTful Web Services
-          Best for Web-Application deployment
-          Leverages Browser for user authentication
-          Synchronous request/response pattern
-          Simple to program
-          Simple to deploy -- publish new URL
-          Secured using TLS, server or mutual authenticated
-          More friendly to mashup
-          Leverages HTTP header negotiations

SOAP Web Services
-          Best for Cross-Organization Interoperability
-          Best support for User Assertions
-          Secured using TLS, server or mutual authenticated
-          Supports end-to-end security with WS-Security
-          Intermediary support
-          Synchronous and Asynchronous
-          Well formed interface definition -- WSDL
-          Support for Reliable Messaging
-          Support for Binary attachments
-          Support for multiple attachments RESTful Web Services

HITSP has selected RESTful Web Services as follows:
  • T18 - View Laboratory Result from a Web Application
  • TP50 - Retrieve Form for Data Capture
  • T66 - Terminology Service
  • T81 - Retrieval of Medical Knowledge
  • TP89 - Sharing Imaging Results (Image retrieve) SOAP Web Services

HITSP has selected SOAP Web Services as follows:
  • TP13 – Manage Sharing of Documents
  • TP21 – Query for Existing Data
  • TP31 – Document Reliable Messaging
  • T63 – Emergency Message Distribution
  • T85 – Administrative Transport to Health Plan

Monday, November 30, 2009

ATNA and Accounting of Disclosures

The ATNA audit log enables an Accounting of Disclosures but is NOT the Accounting of Disclosures. It doesn't contain all the events or details, and should not.

I must be very clear that ATNA audit logging is designed and intended for “Security Surveillance” only. It is intended to be used by the security office to detect anomalies that need further investigation. It does not even purport to contain all the information for this further investigation. Further investigation often involves inspection of other things for corroborating evidence such as from non-security audit logs, video camera recordings, door-lock logs, security-guard logs, interviews, etc. In this spirit the ATNA audit log is a best-effort log, meaning that it will record the best most fullest information that it has. This means that if a user-identity is available then it needs to be in the audit log, but if it isn’t (and presumably access control had good reason to allow the event) then none is recorded.

As implied above, the ATNA audit log it-self is expected to be somewhat redundant. This is why the Document Consumer and the Registry are expected to record an audit log event, even though the audit log event is expected to have the same data. This is done so that one can see the anomaly where the Registry is being queried without the appropriate Document Consumer query. But also because it is possible that the Document Consumer can record things like the user identity better than the Registry can. (I use Document Consumer and Registry as examples, Insert any actors and the story reads the same).

The design of ATNA was deliberate to exclude descriptive values, favoring unique identifiers and codes. This was done in full understanding that the security office would have the ability and reasonable cause to get access to the tools for de-referencing the unique identifiers. This means that a patient is not recorded with their fullname, but rather their PID; and the security office uses the same PIX/PDQ or other method as any other application to resolve names into PID or PID into names as necessary. The advantage of this is that the security office knows of the current list of cross-referenced identifiers for a more complete view. This unique identifier lookup of course must be authorized by the access control system and audited by the audit logging system, and thus there is someone watching the watchers. This same thing is done for Document Unique IDs, where a XDS style query on the document unique id can retrieve the metadata, and if necessary the document can be pulled as well. This should also be the system used to retrieve the user identity description, organization identity, etc.

I recognize the ‘federated user ID’ issue that was uncovered in the NHIN. That is that there was no guarantee that the security office would have access to all of the federated user Identity Providers to do this reverse lookup. I would be interested in how the OASIS or Liberty-Alliance folks would resolve that one. Seems this is a common problem not unique to Healthcare. The solution seems to be a business relationship issue more than a technical one. Worse case, I would have the details from a SAML assertion logged somewhere else, rather than include descriptive information in the Security Audit Log. Another potential is to use the local identification used. This local identification can then be tracked into detailed logs of database subsystems, etc.

The ATNA audit log can be used to inform an “Accounting of Disclosures”, but the ATNA audit log must not be viewed as the “Accounting of Disclosures”. First, it contains many events that are not necessary for an Accounting of Disclosures. One important and often overlooked aspect is that it should contain the sub-system change history. Change management of hardware and software is often very important for detecting intrusions, although it is rarely related to any patient disclosure. Second the ATNA audit log is a combined list of all security audit events including all patients and all user events.

Thus we should not look for how the ATNA audit log contains all of the attributes of an Accounting of Disclosures but rather how it can be used to inform an Accounting of Disclosures. In fact there is likely other sources of information that will need to be brought into the reporting workflow to produce a complete Accounting of Disclosures. Indeed the best that one can expect an infrastructure system, such as XCA Responding Gateway, that is recording ATNA audit events to do is provide a list of events that need further investigation.

Given all the above, you should see why the “Plain text Name of the User”, “Plain text Name of the Organization”, “Purpose of Use”, or other attributes necessary in an Accounting of Disclosures are not a part of the ATNA audit log. But the events found in the ATNA audit log would be used to investigate if the event does represent a disclosure, and additional resources would be used to derive these Accounting of Disclosure attributes.

Friday, November 27, 2009

Electronic health records could be a deadly target during a cyberwar

There is so much FUD being passed around on the 'hill'. Much of this is due to lack of spending time reading the specifications. In the attached article "Chad Skidmore" is quoted as worring that an attacker 'could' get into a system and change the clinical values thus resulting in a patient receiving the wrong treatment. I am not going to try to say that the risk is zero, but I would certainly not loose sleep over this one. There are many controls in place that prevent this threat from being realized.

Given that my blog is about Security and Privacy, I will focus on the technical measures. But there are plenty of Policy, Procedure, Protocol, and Human factors that are in play. Let me discuss the HIE solution that has been selected by HITSP. First I will discuss HITSP/SC112, specifically HITSP/TP13, specifically IHE/XDS (Cross-Enterprise Document Sharing), in this system there is a single Registry that holds metadata about each document that has been registered, and one or more Repository systems that hold the documents. The typical implementation would have a Repository in each sourcing organization, meaning that there would be a Repository in every clinic and hospital participating in an HIE . For each document in these Repositories there is metadata in the Registry, of this metadata is a byte-size and a SHA1 hash. Thus, for the threat that Chad brings up, someone would have to get access to the Repository to change the document, in a way consistent with CDA rules; and also update the Registry. They would need to do this all without causing Security Audit Events, which is a topic I will post on soon.

Now, some will say say that attacking both systems is possible. For you, I would offer yet another mitigation that HITSP offers, HITSP/C26 which is another document entry that is related to the clinical document and is an XML-Digital Signature. Thus the attacker would need to compromise the Registry, Repository, and falsify a Digital Signature; all while not creating Audit Events.

And I am sure others will recognize that the transactions are protected by HITSP/T17, otherwise known as mutual-authenticated-TLS. Thus attacking the data on the publication or the consumption side would be very difficult. (Yes I will tip my hat to, CVE-2009-3555, the man-in-the-middle attack now being frantically worked on by the TLS community. We might get a TLS 1.3 out of this and this might drive implementation).

Now, if a lesser system is used to build an HIE then the above can't be said. I know many are asking for a more simple approach. I would like to submit this very small 'Threat', as being a good example of the risk assessments that were considered as part of IHE XDS (see IHE ITI TF Vol 2x Appendix K). This should be seen as proof that IHE did consider a Risk Assessment when designing XDS. This 'Threat' may be mostly FUD, but it is one that I know is on the minds of Clinical people that are being expected to use the data when treating their patients. This is not a Threat to be taken lightly, event if it is handled nicely by the Infrastructure.

Thursday, November 26, 2009

IHE ITI Planning Committee - Decision to select 2010-2011 Profile/White Paper work

As part of the work slated for this coming IHE ITI cycle, there is an Proposal to upgrade the Cross-Enterprise User Assertion (XUA) profile with one or more named options for user attributes to be used for Access Control decisions. This work will leverage the work of HITSP, NHIN, FHA-CONNECT, HIT-Standards, OASIS XSPA, epSOS, and other international implementations that have used SAML identity assertions.

Dear IHE IT Infrastructure Doman members:

As discussed at our Paris face-to-face meeting last month, the Technical Committee has completed their review of Planning Committee recommendations for profile/whitepaper proposals, with the following response (R. Horn):

The ITI Technical committee met 10 and 11 November in Chicago to evaluate the profile proposals.  The overall result is some revisions to work level of effort, and a few detailed proposals have had content revisions to resolve questions.  The revised detailed proposals are in the ITI Technical Committee FTP directory for detailed profile proposals.  The resulting analysis is summarized in this document and spreadsheet.

There was no interdependency among profiles to motivate a priority order change, and there were no size related reasons to motivate a priority change, so ITI Technical recommends doing the six top priority items.  This will utilize the available resources. We suggested approaches to do small work efforts to avoid completely losing
momentum on the remaining two profile proposals.

The ITI Planning Committee will now review the above recommendations and make a final decision as to the slate of profiles/whitepapers to be developed during the 2010-2011 planning cycle.  This very important step will take place the following tcon:

  • Thursday, December 10, 2009 – 11:00am-1:00pm Central time.
  • A calendar invitation and meeting coordinates can be found at this link.

According to IHE governance procedures, members of both the Planning and Technical committees are invited to attend the Dec 10th decision meeting, however only Planning Committee members (with voting privileges) are entitled to vote.

The Agenda for this meeting is as follows:

  1. Role call and establishment of voting procedures
  2. Report from ITI Technical Committee with recommendations (Karen Witting and Rob Horn)
  3. Planning Committee Decision vote
  4. Approve the detailed descriptions for the approved items to be published on the IHE ITI WIKI.
  5. Review of ITI Technical Committee activities and confirmation of assigned editors.
  6. Other business

We thank you and look forward to your ongoing participation.

Charles Parisot
Michael Nusbaum
Co-Chairs, IHE ITI Planning Committee

Wednesday, November 25, 2009

SHA2 is un-mandated

HIT-Standards - Privacy and Security workgroup had selected SHA2 based on the rules and guidance for Federal implementations. I pointed out to the workgroup that SHA2 would have required the use of TLS 1.2 which has very few implementations. I also pointed out that the rules and guidance require SHA2 only for persistent digital signatures, which were not selected for 2011. Therefore HIT-Standards Privacy and Security workgroup has agreed to change their selection to allow for SHA1 with TLS, while encouraging the use of SHA2 for persistent integrity controls.

More details for those that want more details :
The selection of SHA2 is due to Federal Agency requirements by the National Institute of Standards and Testing. The NIST Policy established in March of 2006 results from research showing weaknesses in the SHA-1 algorithms.  The key statement:
March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.
The first miss-understanding is that the vulnerabilities in the SHA1 algorithm does not affect stream use of HMAC-SHA1 which is what is in TLS, so the guidance allows for TLS use of SHA1.
SHA — Secure Hash Algorithm — is used to detect integrity failures, so another miss-understanding was that this was encryption related, but it is not encryption related at all.

The Implementation problem was most compelling as the general purpose operating systems, web platforms, and browsers that supported TLS 1.2 was very small; thus creating a burden on the healthcare industry. Keith did an excellent review of this and I don’t think anyone found any contrary information.

Thursday, November 19, 2009

Indian Outsourcer Arrested for Selling British Patients' Medical Files

No matter what outsourcing agency is used there must be policies and followup to assure that a breach doesn't happen. With Healthcare data a breach can not be revoked, so care must be taken to prevent it. This will get more difficult as the location of the data being operated on is less defined by it's physical location, e.g. when managed in 'the cloud'.
Police in India have arrested the chief of an outsourcing company for allegedly selling British patients' medical records.  Vikas Dhairyashil Bansode and his accomplices claimed to have obtained the data from IT companies in India that were hired to computerize medical records. According to the UK's Data Protection Act, it is illegal to send this sort of information outside the country unless its security can be guaranteed.  The compromised information includes addresses, dates of birth and details of medical conditions.  The police began to investigate Bansode and his accomplices following a documentary that aired in October in which the filmmakers posed as individuals who wanted to buy medical information so they could market health-related products pertinent to the individuals' situations. More and More

Wednesday, November 18, 2009

Keeping Pacemakers Safe from Hackers

We should not go down the ‘Security Theater’ path… That is not to say that this pacemaker problem is ‘security theater’, but rather to stress that ‘risk management’ is the right approach for security overall. Meaning that for any threat the likelihood and impact is used to determine appropriate reaction to that threat. An additional benefit of the risk management path is that security threats can be evaluated together with patient safety threats. Often times a security threat does introduce a patient safety threat, but an important thing to avoid is mitigating an unlikely security threat with a technology that introduces a patient safety threat. As with any risk management there is never zero risk.
*** NIST SP 800-30 Risk Management Guide for. Information Technology.
Communicating with ultrasound could help make implantable medical devices safe from attack. Manufacturers have started adding wireless capabilities to many implantable medical devices, including pacemakers and cardioverter defibrillators. This allows doctors to access vital information and send commands to these devices quickly, but security researchers have raised concerns that it could also make them vulnerable to attack.  More

Thursday, November 12, 2009

Implementing standards takes time.

One of the struggles that those of us that work on developing standards deal with is the separation of bleeding edge new standards vs the practical reality of daily implementation. It takes at the very least 5 years for a finalized standard to show up in a released commercial product.This 5 year lag is not an indication that the standard was too aggressive. Those standards that are too aggressive simply die because no one wants to implement them.  

Some guidelines based on this reality of practical implementation:
A) Simple and effective: Simple is important but it must also be extensible. Too complex is too hard to fix when things go wrong. Simple is affordable and effective. The simple security standards support organization-to-organization controls very well. I know that people will not believe that this is all that is needed to start off, but it is the right ‘simple and effective’ beginnings.
            ATNA – Mutual-Authenticated TLS
B) Outbound transactions only. The base document sharing standard (XDS) and supporting infrastructure (PIX/PDQ) are all outbound requests. This limits the complexity for a small network operator as there is no need to have inbound transactions. These outbound transactions traverse a firewall easily, and the mutual-authenticated TLS assures that the correct destination is the only system that gets connected to while assuring the HIE that an authenticated trusted client has connected. In a solution that uses point-to-point transactions the small network operator would need to break a hole in their firewall to allow the inbound point-to-point transactions.

C) Organization-to-Organization: This means that access controls are in place at the system only to the extent that it is clear an organization has access to the data. Fine grained access controls are enforced at the edge systems as close to the provider and patient as possible. This recognizes that a typical clinical use of a document will need to make a copy because medical records regulations require that once a document has been used for a treatment purpose it must be maintained. Once a document is available locally it must be controlled locally to the appropriate intended use. Although one individual might pull a document, others involved in the treatment of the patient will need access.
            This is supported by an ATNA style where certificates are issued to organizations that have proven they can be trusted
            A useful augmentation is to add XUA (SAML) assertions so that the audit can contain the user identity, and sets up access controls

D) This principle of organization-to-organization goes for consents as well. There should be consents in place that authorize specific organizations for specific intended uses. This should be explicit consent should be the model. Note that emergency-override is a special intended use that can override the lack of a consent.
            This is supported by BPPC style simple policies that are positively acknowledged by the patient/consumer

E) All actions on PHI are audited using open standards that are used very commonly in other industries and are commonly built into operating system platforms.  The underlying syslog standard is commonly supported by operating system and databases. Thus the additional specification for healthcare specific events adds to this underlying standard. An important aspect of the syslog protocol is that it natively supports architectures where Audit Record Repositories will automatically forward filtered events, such as those associated with HIE interaction. The events support security surveillance, and can be a major source of events for an accounting of disclosures.
            ATNA – Security Audit Logging using RFC3881 + SYSLOG-PROTOCOL

F) Consistent Time: This is almost a shame that we need to specify the use of the Consistent Time profile. This profile is a very simple profile that simply says to use SNTP or NTP to synchronize the system clock to a configured trusted source of time. In this way audit log events are all coorelatable even if they come from different systems. This consistent time is also very important to assure the medical record is also accurately time stamped. SNTP or NTP has been included in all operating systems released this decade, and for many operating systems it is even turned on by default (e.g. Windows installation out-of-the-box will turn on SNTP and synchronize with the time source at ''). So in most cases one must work very hard to not be using consistent time.
          CT – consistent time

G) Extensible: These methods are the basis of future support for coded-policies (XACML+), federated-user-assertions (XUA+),

Wednesday, November 11, 2009

FDA issues reminder to clarify cybersecurity issues

FDA has said this before, a reminder indicates current problems.
The FDA issued a notice saying it does not regulate changes to medical device software developed for cybersecurity purposes. The agency also advised device firms to be responsible when it comes to addressing computer viruses and other cybersecurity threats, as well as collaborate with hospitals and clinics to solve such issues. More

Direct from the FDA

HIMSS Survey: Health providers not ready for new privacy rules

This should be no surprise. As much as I would love for the results to be better, I think that this represents the perceived risk vs cost.
Many healthcare organizations are not prepared to meet tougher privacy and security terms contained in the health IT stimulus law, according to a survey by the Healthcare Information and Management Systems Society. The HITECH provisions of the law strengthened penalties for mishandling personal health information by providers. More
Updating this post with another article on the subject of the need and potential for more security enforcement. More

OASIS Approves SAML and XACML Healthcare XSPA Profiles as Standards

This has been pulled into HITSP TP20, and will be the one of the inputs to the IHE updates to the XUA profile this year.

OASIS announced two Cross-Enterprise Security and Privacy Authorization (XSPA) profiles have been approved at OASIS Standard level. The OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee was chartered to "specify sets of stable open standards and profiles, and create other standards or profiles as needed, to fulfill the security and privacy functions identified by the functions and data practices identified by HITSP, or specified in its use cases."  The XSPA-SAML profile describes a Cross-enterprise Security and Privacy Authorization (XSPA) framework using the SAML core standard and specific attributes to satisfy requirements pertaining to information-centric security and privacy within the healthcare community.
See also the XSPA XACML profile:

Sunday, November 8, 2009

HITSP Webinar - Security, Privacy and Infrastructure

I will be presenting the current HITSP Security, Privacy and Infrastructure constructs.

 The Healthcare Information Technology Standards Panel (HITSP) is identifying the standards that will support the exchange of healthcare information across the United States.  Learn more about the Panel and how you can engage in shaping the future of HIT interoperability during a series of free webinars - one for each month of 2009.

Security, Privacy and Infrastructure

Date:                    Thursday, November 12, 2009                
Time:                    2:00-3:30 pm ET

What you will learn
During this 90-minute webinar, participants will learn the overall structure and fundamentals of HITSP’s new Service Collaborations and their relationship to HITSP Capabilities, Constructs and Interoperability Specifications.

  • Understand the core concepts and components involved in HITSP’s Privacy and Security Service Collaborations, including Access Controls, Security Audit, and Patient Identification Management.
  • Demonstrate how Privacy and Security Service Collaborations can support ARRA’s Meaningful Use, leveraging existing HITSP constructs and components.
  • Learn how to find, navigate, and use HITSP Service Collaborations documentation.

Who should attend

Consumers, government representatives and policy makers, healthcare providers, standards developers, vendors, and any other interested stakeholders.


Jonathan Coleman, Principal Consultant, Security Risk Solutions, Inc.

John Moehrke, Principal Engineer, GE Healthcare

Participation is complimentary, but advance registration is required at

HITSP Education, Communications and Outreach Committee

Participation during the live event requires both telephone and Internet access.  Sessions will be recorded for playback via the Internet.

Mark your calendars!  
The 2009 HITSP FREE WEBINAR series includes presentations throughout the year. 

§     December – Quality Measures Real World Sites
     Thursday, December 10, 2009 — 2:00-3:30 pm Eastern

All HITSP webinars given to date are freely available online, including descriptions, presentations, and full audio playback. To download the files, visit

For more information, visit or send an e-mail to
 HITSP:  Enabling healthcare interoperability

Monday, November 2, 2009

NHIN, privacy front and center at HIT policy meeting

More little tidbits leak out of HHS/ONC that tell the healthcare industry to WAIT!. They don’t say what is wrong or where things are going, but do indicate that the solution that experts from HIT Standards, HITSP, CCHIT, IHE, ISO, OASIS, HL7 and DICOM have developed is clearly wrong. Thus causing the whole healthcare industry to do NOTHING. This seems very counter productive. We have a very mature architecture based on open standards that have been specialized for healthcare only in the slightest.  I do not understand why a set of standards that have been vetted 3-5 times over in open consensus based organizations should be questioned once again by a PRIVATE group.
The head of federal efforts to boost the use of health information technology told members of an IT advisory panel Tuesday that they need to step back and take a second look at the proposed national health information network, and also come up with some advice on a national policy framework for IT privacy and security that makes sense. David Blumenthal, head of the Office of the National Coordinator for Health Information Technology at HHS, thanked members of the HIT Policy Committee for their achievements thus far. More

The later quote in the article is even more frustrating (bold added by me)…

Blumenthal said the ONC has been “working intensively on NHIN options” and would like to present them to a work group and the full HIT Policy Committee. “I’m not enough of a techie to know whether that qualifies as architecture,” Blumenthal said, “but it looks pretty to me, so maybe we can call it architecture.

ONC Seeks Consumer Views on HIE

I hope this is not just another survey that words the questions such that the consumers have no choice but to answer them a certain way. For example: “Do you want your health data secured?” Duh… No, that seems like a bad idea…

How about probing questions that really get to the heart of how hard the consumer is willing to work to control each and every bit of data? I suspect that the vast majority would be happy with a template policy that segments the data into a few slots each with reasonable Role-Based-Access-Controls that are specific to the Intended-Use.  One template policy is a reasonable OPT-IN, one template policy is a reasonable OPT-OUT-WITH-BREAK-GLASS, and one template is an outright OPT-OUT that allows for no use of data outside the original episode.  I am not saying that these should be our policies, what I am saying is that I suspect that 80% of consumers easily fall into a very small number of policies. This is also not saying that we should not serve the 20%, we should. But we can allow the 80% to go forward and get the benefits of Health IT, while we work on the 20% problem. So, lets see a survey that tests this theory..
The Office of the National Coordinator for Health Information Technology wants a better idea of how health care consumers feel about the national drive toward health information exchange. ONC is asking the Office of Management and Budget for approval to conduct computer-assisted telephone interviews with a representative sample of nearly 2,600 individuals across the nation. More