building a RAID system - 8 drives - drive-net - tapes - preferences

Robert G. Brown rgb at phy.duke.edu
Fri Oct 10 09:35:35 EDT 2003


On Fri, 10 Oct 2003, Alvin Oga wrote:

> 
> hi ya robert
> 
> On Thu, 9 Oct 2003, Robert G. Brown wrote:
> 
> > > tape backups are insecure ...
> > > 	- lose a tape ( bad tape, lost tape ) and and all its data is lost
> > > 	- anybody can read the entire contents of the full backup
> > 
> > Unless it is encrypted.  Without strong encryption there is no
> > data-level security.  With it there is.  Maybe.  Depending on what is
> > "strong" to you and what is strong to, say, the NSA, whether your
> > systems and network is secure, depending on whether you have dual
> > isolation power inside a faraday cage with dobermans at the door.
> 
> just trying to protect the tapes ( backups ) against the casual
> "oops look what i found"  and they go and look at the HR records
> or the  salary records or employee reviews etc..etc..
> 
> not trying to protect the tapes against the [cr/h]ackers ( different
> ball game )  and even not protecting against the spies of nsa/kgb etc
> either  ( whole new ballgame for those types of backup issues )

Hmmm, this is morphing offtopic, but data security is a sufficiently
universal problem that I'll chance one more round.  Pardon me while I
light up my crack pipe here...:-7... so I can babble properly. Ah, ya,
NOW I'm awake...:-)

The point is that you cannot do this with precisely HR records or salary
records or employee reviews.  If anybody gets hold of the data (casually
or not) be it on tape or disk or the network while it is in transit then
you are liable to the extent that you failed to take adequate measures
to ensure the data's security.  By the numbers:

  1) Tapes even more than disk are most unlikely to be viewed casually.
Disks have street value, tapes (really) don't.  There is a high entry
investment required before one can even view the contents of an e.g. LTO
tape, plus a fair degree of expertise.  A disk can be pulled from a box
and remounted in any system by a pimple-faced kid with a screwdriver and
an attitude.  The net can be snooped by anyone, with a surprisingly low
entry level of expertise (or rather a high level expertise encapsulated
in openly distributed rootkits and exploits so anybody can do it).

  2) All three are clearly vulnerable to someone (e.g. a private
investigator, an insurance company, a competitor, an identity thief, the
government) seeking to snoop and violate the privacy of the individuals
who have entrusted their data to you.  HR records contain SSNs, bank
numbers (to facilitate direct deposit), names addresses, health records,
employment records, CVs and/or transcripts, disciplinary records: they
are basically everything you never wanted the world to know in one
compact and efficient package.  Federal and state laws regulate the
handling of this data in quite rigorous ways.

  3) An IT officer who was responsible for holding sensitive data secure
according to law and who failed to employ reasonable measures for
maintaining it secure and who subsequently had it stolen (violating his
trust) would be publically eviscerated.  Career ruined, bankrupted by
suits, tormented by guilt, possibly even put in jail, driven to suicide
kind of stuff in the worst case.  The company that employed that officer
would be right behind -- suits, clean sweep firings of the entire
management team in the chain of responsibility, plunging stock prices,
public recriminations and humiliation.  EVEN IF reasonable measures were
employed there would likely be trouble and recrimination, but careers
might survive, damages would be limited, jail might be avoided, and one
wouldn't feel so irresponsibly guilty.

  4) Strong encryption of the data to protect it in transit is an
obvious, inexpensive, knee-jerk sort of reasonable measure (again,
independent of the means of transport presuming only that the data
passes out of your fortress keep where you keep the cobalt bomb and
dobermans and make all of your staff wear tinfoil caps while looking at
the data).  It might even be mandated by law for certain forms of data
-- the federal government just passed a sweeping right to privacy
measure for health data, for example, that may well have highly explicit
provisions for data transport and security.

  5) Therefore... only someone with a death wish would send sensitive,
valuable data for which they are responsible for security, through any
transport layer not under their direct control and deemed secure of its
own right, between secure sites, without encrypting it first (and
otherwise complying with relevant federal and state laws, if any apply
to the case at hand).

Properly paranoid ITvolken would likely consider ALL transport layers
including their own internal LAN not to be secure and would use
ssh/ssl/vpn bidirectional encryption of all network traffic period.  If
it weren't for the fact that there is less motivation to encrypt the
data on the physically secured actual server disks (so the only means of
access are through dobermans and locked doors or by cracking the servers
from outside, in which case you've already lost the game) one would
extend the data encryption to the database itself, and I'm sure that
there are sites that don't trust even their own staff or the moral
character of their dobermans that so do.  I don't want to THINK about
what one has to endure to obtain access to e.g. NSA or certain military
datasites -- probably body cavity searches in and out, shaved heads and
paper suits, and metal detectors, that sort of thing...:-)

> > However, there can be as much or as little physical security for the
> > tape as you care to put there.  Tape in a locked safe, tape in an
> > armored car.
> 
> dont forget to lock the car/safe too :-)
> and log who goes in and out of the "safe" area :-)

Ya, precisely.  It is only partly a joke, you see.  If my Duke HR or my
medical records turn up on the street, with somebody purporting to be me
cleaning out my bank account and maxing my visa, with my applications
for health insurance denied because they've learned about my heavy
drinking problem and all the crack that I smoke (I don't know where
Jakob got the idea that I don't sit here fuming away all day:-) and the
consequent liver failure and bouts of wild-eyed babbling (like this one,
strangely enough:-), my plans for a fusion generator that you can build
in your garage turning up being patented by Exxon and so forth Duke had
DAMN WELL better be able to show my attorney and a court logs of who had
access to this data, proofs that it was never left lying around in cars
(locked or unlocked), proofs that it was transmitted in encrypted form,
etc.  Otherwise I'm detonating the cobalt bomb in my backyard and Duke
will be a radioactive wasteland for a few kiloyears...(it is only a
couple of miles away).

This is the kind of thing that gives IT security officers ulcers.
Duke's current SO is actually a former engineering school beowulfer (and
good friend of mine) whose voice is scattered through the list archives
(Chris Cramer).  As a former 'wulfer (and EE), he is damn smart and
computer-expert (and handsome and witty, just like everybody else on
this list:-).  However, he sweats bullets because Duke is a huge
organization with lots of architectures scattered all over campus --
Windows here (any flavor), Macs there, Suns, Linux boxen, there are
likely godforsaken nooks on campus that still have IBM mainframes and
VAXes.  Sensitive data is routinely served across the campus backbone
and beyond (e.g. I can see my advisees' current transcripts where I sit
at this very moment).  Even with SSL, this data is vulnerable in
fragments to any successful exploit on any client that belongs to any
partially privileged person and that runs a vulnerable operating system.

Hmmm, you say -- wasn't there recently an RPC exploit on a certain very
common OS that permitted crackers to put anything they wanted including
snoops on all cracked clients (not to mention a steady stream of lesser
but equally troublesome invasions of the viral sort)?  Didn't this cost
institutions all over the world thousands of FTE hours to put right
before somebody actually used it to steal access to valuable data?  Why
yes, I believe that there was!  I believe it did!  However, as one who
got slammed (blush) a year ago on an unfortunately unpatched linux box
and who has seen countless exploits succeed against all flavors of
networked OS over many years, I avoid feeling too cocky about it.  

Nevertheless, Chris just keeps suckin' down the prozac and phillips
cocktails dealing with crap like this and knowing that it is his butt on
line should a malevolent attack succeed in compromising Duke's mountains
of sensitive data (gulp) being served by minions whose primary systems
expertise was developed back when knowing cobol was a part of the job
description (gulp) running on servers with, um "interesting" base
architectures (gulp)...

> > I get the feeling that you just don't like tapes, Alvin...;-)
> 
> not my first choice for backups .. even offsite backups...
> 
> but if "management" takes out the $$$ to do tape backups... so it shall be
> done ...
> 	ideally, everything works ...  but unfortunately, tapes
> 	are highly prone to people's "oops i forgot to change it
> 	yesterday"  or the weekly catridge

They are indeed (as the example I gave of a recent small-scale disaster
at Duke clearly shows). A site run by a wise IT human would use a pretty
rigorous protocol to regulate the process so that even if you have e.g.
student labor doing the tape changes there is strict accountability and
people checking the people checking the people who do the job, and so
that tapes are randomly pulled every month and checked to be sure that
the data is actually getting on the tapes in retrievable form.

You can bet that Duke has such a process in place now, if they didn't
before, although Universities tend to be a loose amalgamation of
quasi-independent fiefdoms that accept control and adopt security
measures for the common good and hire competent systems administrators
and develop shared protocols for ensuring data integrity about as often
and as easily as one would expect.  (Sound of Chris in the background
crunching another mylantin and washing it down with P&P:-) So in place
or not, the risk remains.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu




_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list