Re: When to encrypt

In the last exciting episode, dflists(at)iinet(dot)net(dot)au (Derek Fountain) wrote:
> It seems silly to tell him to encrypt everything, including customer
> names and addresses, etc. - I've never heard of DB admin
> recommending such action - and it'll have an impact on
> performance. So where do I draw the line? Encrypt everything on the
> basis that it adds a layer of security? Encrypt nothing on the basis
> that there shouldn't be any way of accessing the sensitive stuff so
> the extra security isn't necessary? Or encrypt a few things, just in
> case? What do people recommend?

There is a model for doing this sort of thing; look at Peter Wayner's
_Translucent Databases_:

<http://www.wayner.org/books/td/>

"Most databases provide elaborate control mechanisms for letting the
right people in to see the right records. These tools are
well-designed and thoroughly tested, but they can only provide so
much support. If someone breaks into the operating system itself,
all of the data on the hard disk is unveiled. If a clerk, a
supervisor, or a system administrator decides to turn traitor,
there's nothing anyone can do."

It's worth pointing out that the really serious classes of security
breaches are of the latter sorts.

I have seen several reports, of late, of _serious_ security breaches
at major banks in my country that are, in a sense, of this nature.

One of the banks, CIBC, had a central 1-800 number to which funds
transfer request information was to be faxed by branches. A typo in
the number, regularly made by branch staff, led to tens of thousands
of records containing sensitive personal information being sent to a
junkyard in West Virginia.

Then there was the time medical billing records were used as props on
a children's show.
http://www.medbroadcast.ca/health_news_details.asp?news_channel_id=1000&news_id=2279&rating=1

In the same jurisdiction, ISM (which used to be an IBM consulting
subsidiary) lost a disk drive containing client data for multiple
insurance companies as well as multiple government departments. It
appears an employee stole it in order to get a free disk drive; had
the intent been more ominous, the results could certainly have been
bad.

There are database vendors that promote that they are "more secure" as
a result of offering data encryption schemes; this seems a red herring
as in order to be able to use the data, the encryption keys must
correspondingly be available _in the database engine_, which makes
them likely to be readily accessible by the very people that would be
most dangerous should they "turn traitor."

That's not even the worst part; if the encryption keys are sitting in
the DBMS, that even makes them vulnerable to capture by an outsider
who finds a way to inject outside code into some DB interface.
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://linuxfinances.info/info/lisp.html
Rules of the Evil Overlord #127. "Prison guards will have their own
cantina featuring a wide variety of tasty treats that will deliver
snacks to the guards while on duty. The guards will also be informed
that accepting food or drink from any other source will result in
execution." <http://www.eviloverlord.com/>