I'll "hack" out some further insight in addition to what's already been
shared....
First, let's start off with some basics, and I'll complicate from =
there:
TSM & ADSM were not designed for physically unsecure environments.
Meaning: If I have physical access to your server and you don't have =
me
locked out through other means, I'm going to go play and you can't stop =
me.
Especially if I can get to the dsmserv console.
Workaround: Lock your machines.
Physical access to tapes: If I can steal your tapes, and I have
rudimentary tape knowledge of read / write and so forth, I will NEVER
figure out what's on those tapes. Well, for the hacks out there =
"almost
never". With physically stealing tapes & *really* advanced knowledge, =
I
*might* be able to hack something together. We (TSM) don't offer that =
as
an advanced data recovery option. Does that tell you something?
Resolution: The "cost" to attack your site in this manner just =
isn't
worth it. ie. there's "cheaper" means of attack. We're also =
addressing
this issue through some other requirements.
Caveat: If you're working with the DOD / CIA / NSA / etc... on
classified+ docs, discuss with them what they see as reasonable
precautions. They're familiar with our product and they're very =
familiar
with their requirements.
Internal Rogue client or trying to act as admin: Without having been
granted access, I would have to hack my way in. There are various =
levels
of security that you can set with given IDs. The default (simplified) =
is
that as a client, you really only have access to your own data. Can
passwords be hacked? Sure, but that's outside of TSM's control. We =
don't
have algorithms to "force" strong passwords or things along those =
lines.
Resolution: Work with your enterprise to use strong passwords if =
this
is a concern.
Snoop on network: Turn on authentication & all conversations between
client & server become encrypted. We use a "double-handshake"
authentication process that's pretty robust and relatively tough to =
crack.
Caveat: Our encryption algorithm strengths could be better. They
aren't bad, just they could be better. It depends upon how paranoid =
you
are. We are examining this requirement, so I would definitely suggest
bringing it up with your marketing rep.
Another process working on your server: Mmmmm, this kinda boils down =
to
the access granted to that remote(?) process and the level of security
inherent in the OS. More or less out of TSMs control and goes back to
point 1.
In and of itself, I would have to rate TSM a pretty secure application.
There aren't any backdoors; there aren't any "easy" loopholes for =
someone
to sneak in with; for different reasons, we don't just write the data
straight to tape; and we don't automatically assume clients are who =
they
think they are (again for different reasons).
Without further knowledge of your requirements, it's difficult to =
comment
further. As you can tell from my email address and .sig, I'm biased. =
But
I haven't been able to hack my team's product yet... :-)
Glen Hattrup
Tivoli Storage Manager
Server Development Team
Debbie Cavallucci <debcav5 AT HOTMAIL DOT COM>@VM.MARIST.EDU> on 04/06/2000
07:17:45 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: ADSM and Security
Our organization is considering the usage of the ADSM system. I have =
not
been able to find too much information regarding security. What =
security
issues/strengths can anyone provide me regarding their usage of the =
system?
How easy/difficult is it for data stored on the sytsem to be obtained =
by an
unauthorized source? Any issues with compromised systems?
Any information anyone can provide will be greatly appreciated.
Thanks!
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
|
