Re: HIPAA - Mailing list pgsql-admin

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