Thread: HIPAA
It looks like that also USA-resident DBAdmins have to protect their data, at least when their data are related to someone else's personal health: http://www.cms.hhs.gov/hipaa/ http://www.hhs.gov/ocr/hipaa/ http://www.hipaa.org/ This seems to give to this "db encryption" issue the status of "global relevance" that would deserve a more systematic approach. I mean: no homegrown solutions - rather have the community to develop a specific, standard extension of PostgreSQL and put it into the distro. I wonder if it is the case to contact the PostrgreSQL developers and signal this (new and annoying) issue. Any comment? ----------------------------------------- Alessandro Bottoni and Silvana Di Martino alessandrobottoni@interfree.it silvanadimartino@tin.it
On Mon, Mar 08, 2004 at 12:07:23PM +0000, Silvana Di Martino wrote:
> This seems to give to this "db encryption" issue the status of "global
> relevance" that would deserve a more systematic approach. I mean: no
> homegrown solutions - rather have the community to develop a specific,
> standard extension of PostgreSQL and put it into the distro.
Just to throw another wrench into the works, you might want to think
about some of the observations on what data you _really_ need that
are in Peter Wayner's _Translucent Databases_ (Flyzone Press, 2002.
ISBN 0-9675844-1-8). Many of the techniques are not particularly
novel, but the discussion in the beginning about deciding just which
data you _really_ need is, I think, very helpful. There's a tendency
to collect data just because one can, and the new data protection
laws are an attempt to find a techno fix to the problem. (I still
like it that someone is spending some time on improving the crypto
stuff, though.)
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
On March 8, 2004 09:07, Andrew Sullivan wrote: > On Mon, Mar 08, 2004 at 12:07:23PM +0000, Silvana Di Martino wrote: > > This seems to give to this "db encryption" issue the status of "global > > relevance" that would deserve a more systematic approach. I mean: no > > homegrown solutions - rather have the community to develop a specific, > > standard extension of PostgreSQL and put it into the distro. > > Just to throw another wrench into the works, you might want to think > about some of the observations on what data you _really_ need that > are in Peter Wayner's _Translucent Databases_ (Flyzone Press, 2002. > ISBN 0-9675844-1-8). Many of the techniques are not particularly > novel, but the discussion in the beginning about deciding just which > data you _really_ need is, I think, very helpful. There's a tendency > to collect data just because one can, and the new data protection > laws are an attempt to find a techno fix to the problem. (I still > like it that someone is spending some time on improving the crypto > stuff, though.) > > A Many, many moons ago when I was young and stupid, I was in an intelligence trade in the Cdn Navy - COMINT/SIGINT. it never ceases to amaze me at how consistantly people underestimate the information that can be taken from a datum - especially when aggrigated with data from other sources.
On Mon, Mar 08, 2004 at 05:25:34PM -0500, Gorshkov wrote:
> it never ceases to amaze me at how consistantly people underestimate the
> information that can be taken from a datum - especially when aggrigated with
> data from other sources.
This is actually part of the argument for why you just shouldn't
store or ask for a lot of stuff in the first place. Of course it's
true that the little bit of data that you have can be aggregated with
the little bit of data someone else has in case a dedicated attacker
is trying to build up a full data set. But given that there are
these data, nobody is actually going to be able to prevent such an
attacker anyway. All you can do is limit your own liability in
exposing data; and that means collecting as little (not as much) as
you can, and then further attempting to protect the data you actually
do collect.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie
Martha Stewart called it a Good Thing when listsubscriptions@oghma.on.ca (Gorshkov) wrote: > On March 8, 2004 09:07, Andrew Sullivan wrote: >> On Mon, Mar 08, 2004 at 12:07:23PM +0000, Silvana Di Martino wrote: >> > This seems to give to this "db encryption" issue the status of >> > "global relevance" that would deserve a more systematic >> > approach. I mean: no homegrown solutions - rather have the >> > community to develop a specific, standard extension of PostgreSQL >> > and put it into the distro. >> >> Just to throw another wrench into the works, you might want to >> think about some of the observations on what data you _really_ need >> that are in Peter Wayner's _Translucent Databases_ (Flyzone Press, >> 2002. ISBN 0-9675844-1-8). Many of the techniques are not >> particularly novel, but the discussion in the beginning about >> deciding just which data you _really_ need is, I think, very >> helpful. There's a tendency to collect data just because one can, >> and the new data protection laws are an attempt to find a techno >> fix to the problem. (I still like it that someone is spending some >> time on improving the crypto stuff, though.) >> >> A > > Many, many moons ago when I was young and stupid, I was in an > intelligence trade in the Cdn Navy - COMINT/SIGINT. > > it never ceases to amaze me at how consistantly people underestimate > the information that can be taken from a datum - especially when > aggrigated with data from other sources. I'd like to think you misspelled "aggravated" there :-) The US situation of SSN numbers being widely used as personal identifiers has been quite spectacularly disastrous for personal security. My credit union finally "saw the light" a couple of years ago, and decided to use their own randomly generated account IDs; I gather that many (most?) US companies have been taking the same strategy with employee and customer account numbers. For different organizations to use different keys is not a total panacea, but the lack of uniqueness has been pretty harmful. Wayner's book is certainly pretty good on the subject; it may not be a NIST/FIPS/ISO standard, but it certainly presents the security issues coherently. What is pretty clear is that this kind of application requires that there be a use of data encryption that is controlled _outside_ the database layer. There may be attempts made to sell the notion that the Right Solution requires using some particular product, such as Trusted Oracle; you can expect that to be pressed by vendors that have products they want to push. Unfortunately, this may well worsen security, by putting trust in a layer that cannot provide security. -- let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;; http://cbbrowne.com/info/rdbms.html "I think we might have been better off with a slide rule." -- Zaphod Beeblebrox