You brought up a good point - and a question that is seldom raised.
In the hurry to get problems solved quickly, many people don't go
to the trouble to think about the "what ifs" involved when vendors
dial-in to their systems / networks. Hats off to you for forward
thinking.
I have had to deal with this problem a number of times in a previous
life, and in a nutshell, I would be *extremely* cautious about letting
*any* vendor log into my network to solve anything. You have no way
of knowing (or verifying) how secure the vendor's network is, or who
the person is (could be a hacker with a daytime job). (Also, if the
other company had a worm running loose on their network and you connect
the two networks together...). 8^(
In almost all situations, there are alternatives. I would recommend
finding one that avoids having the vendor log in or at the very least
restrict things so much that the damage is contained.
A few possible ways of handling the situation (in no particular order).
1) "Sorry, but our policy doesn't allow dial-in connections". Probably
won't work, but it's worth a try. The other company might even suggest
alternatives. If they want your business, they will work with you on
this. If they balk, ask to log onto their network. 8^)
2) Troubleshoot the problem over the phone (like most helpdesks do).
This assumes that the person performing the actions understands the
technical ramifications of what they are doing.
3) The PC Anywhere idea was pretty good, but have fun trying to find someone
to monitor the keystrokes at 2am. Also, they person doing the monitoring
may not necessarily understand what the vendor is doing and would not be
in a position to detect/prevent unauthorized or malicious activities.
Aside from that, it is a good idea. (Friendly greetings back to Holland) 8^)
4) Create a copy of the system to be troubleshot, throw it on an isolated
LAN (with no other systems on it, disconnect it from all other networks),
and provide a secure dial-in service. Don't forget to tape up and mark
the ends of the cables so that no one accidentally connects the isolated
LAN to your internal LAN. Any damage is contained to the system / isolated
LAN.
5) Have them appear on-site to solve the problem. <== My favorite as the
person can be identified/authenticated.
6) In all cases mentioned above, the vendor should have signed the
appropriate NDA, Confidentiality, and Liability forms. The forms
should be appropriately worded (similar to the infamous s/w license
agreements, but with the deck stacked in your favor). Put it in
writing that if anything happens, that they are responsible for
reinbursing you for all expenses & damages, system rebuilds, etc.
7) Tap the incoming line and have the output go to a printer (after
writing the date/time started and initialling it). Just remember
that the printout must be interpreted in the proper context of
when the commands are given. (There are ways to get around this,
but not in a public forum).
8) FTP the log files to them & FTP the solution from them.
All of the above depends on the value of what you are protecting, and
how much management support you will receive in your wise decision to
restrict dial-in connections. If it was me, I wouldn't let the dial-in
connection happen if there was any alternative.
Best Regards,
Frank
|
|
