> > Whenever an attribute is selected in a query, a trigger will check
whether
> > the attribute is encrypted etc.
> >
> This seems manageable in a scenario where a small number of users will
> issues queries for data for which they, by and large, have the
> passphrases for. The larger the system is in terms of passphrases (who
> get's them?, patients and clincian's and staff), then the more likely it
> is that the query process will demand so many passphrases that the
> system slows to a halt waiting for you to either provide them or say you
> don't have them.
>
> In other words, this seems perfectly workable for a small practice
> system, but not a large IDS.
It is scalable. Depends on teaching & sticking to security policies. Think
of it as a pyramid.
You have a very broad base with low-level sensitive data (name, address,
some pathology, some financial details etc.) These are either not encrypted
at all and only protected by the usual access restriction, or encrypted with
a passphrase known to all health staff. In that case, the security gain is
only marginal as compared to no cryptography, but still makes it a wee
little bit harder for opportunistic intruders.
Then you have slightly more sensitive data, like progress notes. Only
doctors and maybe charge nurses may have access to this phrase. Pinching the
passphrase from this group requires more criminal energy than getting it
from the janitor and is an additional obstacle for medium-level motivated
intruders.
On top of the pyramid is a tiny amount of data with highest sensitivity
regarding breach of confidentiality. This (and only this) data is protected
with pass phrases known only to a selected group of doctors (maybe only one)
and the patient himself (or not even the patient). This is very hard to
crack and requires a high level of motivation / criminal energy to overcome.
Horst
