As one of the small number of individuals involved in the creation of the IHE Audit Trail and Node Authentication (ATNA) Profile, I am excited to see a vision coming to life. There are those that see the Access Controls as being the tool used to control fine details, this is much harder to do in healthcare give the fluidity of workflows, variability of data, and critical to safety. Thus an Accountability model that leverages Audit Controls are more often used in healthcare. The Audit Controls model supports just as detailed of Policies, but they are enforced using professional ethics and audit log analysis. There are still course Access Controls that keep out those that should never be given access, but those that might need access are given access rights. Along with this is strong training on the policy informing the users that they are under. When using Audit Controls to enforce Accountability there is much more reliance on good behavior enforced through swift punishment as said in an article this week Train Employees Not To Snoop; Fire Those Who Do. This Audit Controls model is not critical to the success of ATNA, but the success of the ATNA audit log is critical to the success of an Audit Control model.
At the time we wrote ATNA we knew that the vendors involved in Healthcare software and medical-devices are experts in; healthcare software and medical devices; and were quite bad at security. This holds true today, although it is getting better. What we wanted to do was leverage existing security infrastructure and keep those developers focused on great healthcare software and medical-devices. This is shown through not just IHE ATNA, but alsoConsistent Time Profile, Document Digital Signature Content Profile, Enterprise User Authentication Profile, Personnel White Pages Profile, Cross-Enterprise User Assertion Profile and to a lesser extent Basic Patient Privacy Consents Profile. All of these profiles tried to invent as little as possible, tried to use as little specialization for healthcare, and use as much of existing and mature IT.
Even within IHE ATNA there are many threads that are exciting to see continue to be a strong force today (like: Mutually-Authenticated-TLS, and Federated Access Controls at the edges). The specific topic of this article is the Audit Logging functionality. As stated above, the healthcare software of the time was really good with algorithms but not good at all at figuring out how to make something useful out of a security event log. At the same time there was an IT industry that was getting quite good at analyzing firewall logs, intrusion-detection logs, database health logs, hard-drive failure logs, etc. We figured that by letting the healthcare software developers focus on developing great healthcare software, and letting audit-log analyzing developers spend their time analyzing audit logs; that we had the helped both groups out.
It was not a smooth path. We tried to find a standards organization that was interested in developing a security audit log message that would meet healthcare's needs for security-surveillance. The usual set of standards organizations for healthcare (HL7, DICOM, ISO, and ASTM) did not think that they were the right place to develop the standard. So, off we went to a neutral third party, IETF. At the time they would allow anyone with interested parties develop a standard. We started with ASTM-E2147-01 "Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems". Through much difficulty, mostly due to growing pains in IETF, we produced RFC-3881. The problem was that IETF rules forced us to keep it 'informative', ok we could have gone through the pain but we found that DICOM would make the schema normative as part of specializing it for DICOM purposes. We then could reference this normative specification in IHE and produce ATNA.
All we needed was a normative transport, which was many more years of struggle. We pointed to the BSD-SYSLOG specification that captured what most everyone was doing with UDP. We pointed to Reliable-SYSLOG, as a freshly minted IETF standard that seemed to have all the right characteristics. Well Reliable-SYSLOG failed in the market, it was too difficult and was not perceived as being worth the extra trouble. We pushed the SYSLOG community to please give us normative specifications and a specification for what most all systems were doing with TCP rather than UDP. Many years later we now have SYSLOG-Protocol, and a binding for UDP and TCP. Even that couldn't be easy as IETF rules forced some unfortunate things.
Along the way, NIST SP800-92 Guide to Computer Security Log Management would all but endorse our model even if they didn't know of IHE-ATNA. All of the above specifications are really still moving ever so slightly, but are mostly well established. The most interesting development is one in HL7, where a 'service' is being defined specifically for 'accounting of disclosures'. As part of this project we are defining what a audit log event for a disclosure would look like if one knew all the possible attributes (who, what, when, where, why....). This might be an academic exercise, but will give us room to build audit log analysis on. The ATNA can inform an Accounting of Disclosures.
So through all of this growing pain we have tried hard to show at the HIMSS Interoperability Showcase what an audit log repository would look like. It has never really been too exciting, and mostly we must show off incomplete applications. However through much of this I am seeing at least two vendors fighting hard to make the audit log analysis a highly valuable tool. HIPAAT has been in the trenches with us for some time, and I have also encouraged FairWarning. Any others that are out there are welcome to post a comment to this article.
The good news is that we continue to see that audit log analysis does work to detect and convict those that would abuse their access rights against policy. It is important to not just have technology but to use the technology securely.
No comments:
Post a Comment