Hi All, If one resorts to hardware to support security be sure to post guards. WWII proved than reliance upon hardware devices to provide adequate security is misplaced.
Hardware components in a security system are acceptable if the software can re-configure them and alter even their basic functionality, e.g., re-configurable computer systems and networks. One significant advantage of ATM networking was the use of fixed-size cells to transmit data (essentially a switching technology). Try reconstructing cell-based data on the fly or store data in cellular format with separately stored reconstruction algorithms. The problem was solved long ago - cellular systems. Any static security system is sensitive to determined efforts. No security or inadequate security mechanisms are invitations. A single breach will likely destroy confidence. The ability to re-configure and re-deploy is essential. Regards! -Thomas Clark Tim Churches wrote: >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. > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
