ADSM-L

Re: 3494 Volume Stealing

2002-03-21 00:55:57
Subject: Re: 3494 Volume Stealing
From: "Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
Date: Wed, 20 Mar 2002 23:28:12 -0500
I guess being a defense contractor I have a different take on data security.
I call the Internet the "Network of Death" because of the potential
exposures that are there because the "that's good enough is rampant".  In my
business it is either secure or it isn't.  I sell security of their
information to my customer as much as I sell the product.  For this reason
we have to jump through hoops to protect information when the product does
not complete the solution.  In the case of the 3494, I cannot share it in
any way with more than one customer making it expensive.  The reason is I
cannot block a rogue host from doing something it shouldn't.  A host becomes
rogue when it is broken into.  It is not a question of if but when.  I need
to be able to have many tiers of security.  Sharing resources is not
possible in the 3494 environment without creating an exposure unless all the
systems attached are of the same security categorization and enforce the
same security constructs meaning they are owned by the same management team.
So, again, my take is just a little different.

One thing I can tell you is there were a room full of people in various
industries concerned about this issue at Share.  And, like at Share, we as
competent professionals can agree to disagree on the grounds of our business
requirements.  That is why we have a thing called requirements voting, a
democratic way to influence the direction of IBM dollars spent on research
and development.

I agree with you on the subject of not doing library range scans because you
have no idea what is going to happen.  I do not use them either.  Not even
on a move drmedia command.  The bottom line if you do a '*' and have no idea
what is there you have no idea what you will get.  And, actually, in our
environment we do a lot of moving ownership of LUNs around in our Sharks as
workload requires them (unassign from one and reassign to another) so I get
to decide who can see these LUNs at any point in time.  And, in fact, I can
allow more than one system to see the same LUN if I wish.  The Shark
autonumbers the LUNs.  That is a minor semantic of the discussion.  The
important thing from my point of view I get to say who can see what LUNs.
And, no matter what kind of GOD you are you cannot get past that.  All Share
is asking for is at the hardware level of the 3494 allow us to do the same
thing for volumes whether they are virtual VTS volumes or physical volumes.
I think you would agree even in the financial industry this would be an
added value security function when many hosts have been given mtlib
equivalent access to the Library Manager.  Thus comparing the ESS to the
3494 is very applicable to this discussion when you think of the ESS being
delivered by default with LUN access restricted, but you can turn it off and
the 3494 is delivered with no volume security and no way to turn it on.

Thanks for this healthy debate of the issues.  It helps put into perspective
the quality of people on this List Server and their ability to
philosophically debate a subject.  We all win from a discussion like this.
It fuels the best in innovation by our vendors as they develop future
products.

You get one more rebutal.


<Prev in Thread] Current Thread [Next in Thread>