Today a news release was the topic of Bruce Schneier blog, the news release was about a recently released Security Audit report on the Vancouver Coastal Health Authority. The report was withheld from the public for 6 months so that the worse of the issues could be resolved, I can only assume they were. It is no surprise that Bruce liked the report and wished that others, pointedly the USA should do the same. On this topic I can report that some healthcare providers and HIE do actually do this; but I suspect not enough. I am absolutely confident that healthcare networks are far better secured than they were 10 years ago when it was common for a hospital to have absolutely no firewall at their boundary to the internet. Progress, but we must always push for more progress.
I have a few observations on this specific report. It is only 37 pages long, and quite readable. Within the 37 pages is an executive summary, response by VCHA, and a slightly detailed report. The report looks very official and is proud to declare that they used the ISO/IEC 27001 and ISO/IEC 27002. These are motherhood and apple-pie to a security expert, but they are mostly specifications that a consultant can build a business around. The group of Auditors are clearly general IT security auditors as they totally missed the Healthcare specialization in ISO/IEC 27799, they did not consider Patient-Safety, they did not consider Medical Records Retention Regulations, they did not consider legitimate secondary use, they did not consider legally mandated access such as a court order. I do note that the VCHA response DOES recognize the need to protect patient safety, although at that point it seems like a straw argument. Then I get to the end and they have two pages of glossary terms ALL referenced to Webopedia and/or Wickipedia.
The main problem that was found was that there was an utter lack of POLICIES. This is step ONE. Without Policies it is imposible to secure anything. An anonymous source tells me that "B.C. really rushed their EHR project, had some really ridiculously short timelines. This seems to be the result of extreme fast-tracking; everything except for getting the thing working was brushed aside, with a "we'll get to it later", and then they didn't." Those of us that work in Interoperability and Technical Standards harp on this day and night. In HITSP we wrote a Technical Note (TN900) totally dedicated to this ONE thing that must be done FIRST. IHE also has many of these including in their white paper on Security/Privacy in an HIE. Without Policies I am not sure why they even continued with the Audit, everything else can't be declared out-of-policy.
Knowing that there are no Policies, it is hard to argue that the Identity and Access Management was poor, although there are plenty of observations about how poor they were. Some of these are hard to argue with, but other practices could be legitimate. The fact that accounts are not immediately disabled, which would be general IT security best practice, could be legitimate as health professionals often move around within the same community sometimes as a consultant, sometimes as an employee, sometimes as a third party, sometimes as a defendant. The fact that users are not segmented into special roles is a recognition (a) healthcare providers tend to have many roles covering a range of responsibilities, (b) healthcare providers tend to do what ever they can to help patients often going above their defined role, (c) one organizations definitions of roles is very likely NOT the same as another organization, and (d) no one actually has knowledge of who really has a need-to-know and who doesn't (many have tried and failed). Thus everyone that should see patient data is given the single role that gives everyone rights to see patient data. All other roles are considered unnecessary. This might not be a good policy, but lacking policy this is what will prevail. Policies are to blame. It is not uncommon for Healthcare to use a rather liberal policy for Access Control that gives access to anyone that might have a reasonable need; but this is tempered by Policy that instructs them to behave correct; AND audit logs are regularly analyzed to detect abuse and punish according to the Policy.
Records retentions in healthcare is not the simple world of general IT records retention. The rules of Medical Records Management prevail here, not the typical rules of IT. Who are the Auditors to determine that something is irrelevant? Who are they to determine that the expiration of the records is not mandated by regulation, it is common for medical records retention rules to require Life + 3 years. Most choose to keep all data online because they really don't know when a patient has Died, there are no regulations that require ALL healthcare providers to be notified when a human dies. Plus the data might legitimately be allowed for research use. Again, lack of Policies make this Audit measurement irrelevant.
Last but not least is the observation that there was no monitoring of the audit logs. Not even the general IT security log monitoring to detect intrusions and such. I push Audit Logging as the next thing beyond hardening, because post-analysis of behavior can detect abuse and swift reaction to abuse can shutdown future bad behavior. This is not the best approach, but given that the problems listed above around access controls and identity management are not going away, audit controls can at least be used. There are very well documented cases where this has worked: Octuplets, U of Iowa , St Vincent, Governor of Michigan, etc. And they are critical to enable the Accounting of Disclosures.
Discussions of Interoperability Exchange, Privacy, and Security in Healthcare by John Moehrke - CyberPrivacy. Topics: Health Information Exchange, Document Exchange XDS/XCA/MHD, mHealth, Meaningful Use, Direct, Patient Identity, Provider Directories, FHIR, Consent, Access Control, Audit Control, Accounting of Disclosures, Identity, Authorization, Authentication, Encryption, Digital Signatures, Transport/Media Security, De-Identification, Pseudonymization, Anonymization, and Blockchain.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment