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.

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.

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 10^th 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.

Regards,

Charles Parisot

Michael Nusbaum
Co-Chairs, IHE ITI Planning Committee

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.

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

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

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 'time.windows.com'). 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+),

See http://healthcaresecprivacy.blogspot.com/2009/10/what-has-hitsp-done-to-protect.html