On Sun, 2004-03-07 at 10:18, Tim Cook wrote: > On Sat, 2004-03-06 at 14:17, Tim Churches wrote: > > In general, caches should be > > held on encrypted filesystems, either on-disc or in-memory, with the > > keys (or a key to the keys) to the encryption/decryption managed by a > > daemon which purges the keys from memory when asked (eg locking the > > device) or automatically after a short period of disuse. > > Well, now that would certainly be a secure way to handle caching. If I > were worrying about national secrets.
Personal health information is more important than national secrets to the individuals concerned. Furthermore, it only takes the compromise of a handful of individuals' confidential information, and publication of this fact, before public confidence in your EHR evaporates. So I don't think that is overkill. Note, however, the use of the subjunctive "should". That's the way it ought to be done, and it is technically achievable. Unfortunately, browser and OS vendors/writers don't chose to do that by default. But certainly it can be done - on Linux systems, it is quite easy to set up encrypted filesystems and to store the browser cache on these. Likewise on Windows - individual directories can be encrypted (although there are distinct flaws in the way the encryption keys are handled in Windows - still, better than not encrypted). > Do you go to this extreme now (as a manager) when doing your risk > assessments? I am wondering what the total (additional) costs of system > design and hardware resources is when these facilities are implemented. Risk assessment: client workstations are often shared between users and located in insecure locations, laptops are stolen or lost all the time. Thus confidential information which is captured in a cache on these systems needs to be secured. Note that if the EHR user is, say, a physician, then there may be details of hundreds of patients in their workstation/laptop cache. Does this represent a challenge to applications,especially Web browser applications? Yup. Are technical solutions possible? Yup - see above. Is all of this costly? Well, my view is that additional hardware security devices are probably unnecessary (and almost all are unnecessarily proprietary anyway), and the software required to implement what I describe above is free (at least for Linux - on Windows, file system encryption is only available on server versions, I think - at least that is the case with Windows 2000 - not sure with Windows XP/XP Pro). Does the administration and training involved cost money? Definitely, security doesn't come free. Is the expense worth it? See above - only takes a handful of confidentiality breaches before you can kiss confidence in your EHR goodbye for several years. > > I think that in most cases we can reliably depend on locked doors and > holding people responsible for protecting data they are entrusted with. Surely you jest? Client workstations, even in large hospitals (or especially in large hospitals) have to be considered insecure, likewise desktop PCs in doctor's offices - common targets for drug-related burglary, and especially laptops and handheld devices which are pinched or misplaced with monotonous regularity. The same applies to EHR/EMR servers, especially servers which are not housed in dedicated, secured data centres, although even the latter are far from invulnerable - see for example http://www.smh.com.au/articles/2003/09/04/1062548967124.html - and then there is the off-site back-up media etc to consider. > I will agree that security training needs to include this awareness so > that users know how to properly store each of these devices when not in > use. Security engineering is all about building systems which fail gracefully. Certainly training users is vital, but relying entirely on users, or system administrators, or anyone, to always do the right thing is a recipe for inevitable security failure. It is always better to build additional protection into the fabric of information systems, as long as the cost is justified - and that comes back to risk assessment as you note. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20040307/4bba46ef/attachment.asc>
