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

Sunday, November 1, 2009

Panel seeks Rx for secure health data exchange

I am confused by the title of this article. It seems to indicate that there is something going to be said about 'secure health data exchange', yet the article has nothing in it on security. The title seems to indicate that there is something wrong in health data exchanges too, but the article focuses on the testimony of two success stories in both 'health data exchange' and 'security'.

The VA interaction with the NHIN is done through standards that follow and exceeding the HIT-Standards recommendations. Not only that but there is an Open-Source success story deep inside.
“Our greatest success may be the full implementation of care coordination via the NHIN, starting with federal partners like the Veterans Affairs Department and using the standards already recommended for meaningful use,” Andrew Wiesenthal, associate executive director of the Permanente Federation, said on behalf of the Kaiser Permanente Medical Care Program.

The second success story is about Providence Health, who eventually had to turn to 'standards' to get interoperability working. During the question segment of the testimony it came out that this ultimate solution using standards was accomplished in 11 weeks.
Dick Taylor, chief medical information officer for Providence Health and Services, said Providence has learned several lessons from working on data exchange for a decade.

“We have been challenged by our own workflows, by the time-limited and relatively nontechnical environment in our providers’ offices, and by the maintenance ‘tail’ inherent in custom self-designed solutions," Taylor said. "We have learned and suffered from the limitations of read-only access to systems and clinical summaries that can be viewed but not effectively integrated." The situation improved in 2009 as the industry reached a critical plateau of standards-based data exchange, he added.
I am not sure I want to point at the article as it sends such a mixed up message. But  I will.. More