Hello

Since I was the one that started this thread, I thought I should comment on the
risk assessment.

The origins of the data erasure requirement at this site is potentially purely
to limit liability.   This is due to recent practices of the courts of seizing
backup tapes simply to extract email's in order to find memos that support a
given case.   This is nothing new, they used to seize paper memos and personal
files as well; hence the common practice of paper shredding.   However, email
has been found to be persistent due to backups and easily searched since they
are electronic.   It's not so much a case of actively concealing liability but
an issue of defining limits to your liability.

The management perspective is to simply mandate rendering the media unreadable.
Of course technically there are many degrees of unreadability depending on how
much effort one is willing to take to recover the data.    It wasn't that long
ago that every field engineer had a bottle of a solution that would render
magnetic media transparent according to magnetic polarization and you could
actually see the individual bits on the tape; if you had a lot of patience, you
could also see the slight imperfect overwrites from subsequent write passes and
therefore infer what was overwritten, especially if the overwrites were on a
different drive with slightly different  head alignments.   Management doesn't
care about the technical details, they only want the media unreadable.

Obviously, we tried to sell partial overwrites, relabels, obfuscation by volume
pool dilution etc. as assurances of limited liability but Management wouldn't
buy in (not surprising considering the 127 million dollar suit that Texaco was
recently in where backup tapes were seized for email).   It is more likely that
the various solutions were not presented to management in a convincing fashion
but hey, I'm just a consultant and am not the one going up to management with
the solutions that I propose.   However, they would buy in on degaussing
regardless of the relative details of degaussing versus multiple rewrites.
Obviously, I'll implement obfuscation by pool dilution to make it very difficult
for anyone to even identify which tape might once have held the emails in
question without subjecting every tape in the library to detailed analysis but
the fact remains that the relative contributions of all the other techniques
were rejected as not being absolute while degaussing was accepted as absolute.
Note, the alternative suggested by management was physical destruction of the
media.

Almost makes one want to get a vat of that solution and a high resolution
optical scanner so that one could recover data for a price now that millions are
at stake in the corporate world.   One job could set you for life and it's just
a bunch of pattern recognition crap.

Technically, the results of my playing with destroying data are as follows:
     - Sony AIT tapes do not erase tapes when sent an erase command via "mt
erase"
     - The dd command on Solaris 2.7 has been fixed such that you can't just
feed it /dev/null input to generate large outputs
     - Degaussing an AIT tape requires about two to three hours of wait time
before the tape is usable (chip scrambled etc.)
     - A degaussed AIT tape does not have an EOT marker on it so one needs to be
written (mt erase does this)
     - Netbackup's GUI interface ejects but one tape at a time (will be trying
multiples via vmchange tomorrow)
     - Netbackup's GUI injects tapes without checking the barcode on the tape
(so you have to be careful)
     - Convenience outlets in the raised floor server room are all on the least
convenient wall
     - lacking a way to identify expired tapes in a pool from scripts, I've had
to freeze every tape so they would show on bpmedialist

Now if the AIT tapes actually did do an overwrite, I think we could've sold the
"mt erase" solution to management as it would've been a vendor assured erasure
(i.e.: somebody to recoup damages from).   Anyone happen to know if the AIT
drives can be jumpered or otherwise set to actually erase when commanded to do
so?

As it is, we now degauss the tapes with a Radio Shack handheld degausser.   I'm
doing everything manually right now but I intend to write a script that would
use bpmedialist to output a summary of the tapes in the specified pool,
unfreeze, transfer to a hold pool, and eject tapes that have expired; and freeze
all other tapes in the pool (thereby ensuring single expiration dates per tape).
I'll probably be the one running the script daily though I would hope that
someday an appropriate lackey be appointed or hired and to manually degauss the
tapes (some things were easier back when server rooms had 7x24 human operators).
If I could get the AIT drives to actually erase, I could script that and lobby
for that solution to be accepted otherwise I see no alternative but to manually
inject the tapes via the GUI once degaussed, waiting a couple of hours and then
labelling the tapes (so far I've been doing an mt erase to place an eot marker
so that "media error" senses stop cropping up and then doing a bplabel but I'll
try bplabel by itself next time to see if it writes an eot).   Note, if you do
not wait two to three hours, you get I/O errors when you try to bplabel, mt
erase, or even dd to the AIT tape (I miss my old Exabytes).

I guess I can now say that I've had that Dilbert position of Information
Destroyer amongst the many hats that I've had ;)

Regards,
John I Wang
Sr. Systems Engineer
Steverson Information Professionals

---
Enron Broadband Services
Enron Building 1472c
ph (713) 345-4291
fax (713) 646-8063


|--------+----------------------->
|        |          jmeyer AT ptc DOT co|
|        |          m            |
|        |                       |
|        |          11/15/00     |
|        |          12:32 PM     |
|        |          Please       |
|        |          respond to   |
|        |          jmeyer       |
|        |                       |
|--------+----------------------->
  >-------------------------------------------------------------------|
  |                                                                   |
  |       To:     veritas-bu AT mailman.eng.auburn DOT edu                   |
  |       cc:     (bcc: John Wang/Contractor/Enron Communications)    |
  |       Subject:     Re: [Veritas-bu] To ensure overwrites          |
  >-------------------------------------------------------------------|




I have seen a key issue missing from the discussions of how to ensure
that data on a tape is overwritten or destroyed.

This is really a security issue, so the important question is what is
the potential threat and what are the capabilities of the adversary.
Any security related procedure needs to be based on this "threat
model."

For example, writing an EOF at the beginning of a DLT tape makes it
entirely unreadable on any system I personally have used.  As far as I
know, stock hardware and stock device drivers cannot read such a
tape.

On the other hand, the data still exists on the tape.  I do not know
if civilian data recovery firms can recover the data, but equipment to
do the job does exist.

Now, lets discuss the most potent adversaries.  Many people I know
believe that the NSA can recover the data if it has been overwritten
once with a random bit pattern.  56 bit encryption will not slow them
down much more than rot13 :-).  They will be able to produce both the
overwrite pattern and the layer below.  No one I have spoken to will
speculate how many layers down they can differentiate.  Degaussing is
also suspected to be insufficient.  I believe that all governments
really do shred classified tapes into fine powder for disposal.

It is very difficult to know how the capabilities of other governments
and/or large multi-national corporations compare to the NSA.  I try to
never underestimate an opponent.

It does not make alot of sense to me to talk about procedures for
handling tapes until a reasonable model of the threat has been
established.

On a related issue, some threats should be managed through security,
others through businesss insurance, it is all about risk management
and cost management.

--------------------------------------------------
Jonathan Meyer
(781)398-6594
UNIX Systems Administrator
Paramtric Technology Corporation
--------------------------------------------------
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu