From: | Christopher Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: HIPAA |
Date: | 2004-03-08 23:51:56 |
Message-ID: | m3smginbhf.fsf@wolfe.cbbrowne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Martha Stewart called it a Good Thing when listsubscriptions(at)oghma(dot)on(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michiel Lange | 2004-03-09 07:18:37 | Re: Upgrading |
Previous Message | Silvana Di Martino | 2004-03-08 22:43:37 | Re: Database Encryption (now required by law in Italy) |