Mike Papais asked that I compile the responses to my question below and send
it to everyone.
So here goes...
************************************************************
MY QUESTION WAS:
************************************************************
On Wed, 25 Oct 1995, Yalda Mirzai wrote:
> We have been receiving many requests from our system administrators to
>allow "vendors" access to our internal network via the firewall for
"technical
> support" or "troubleshooting" purposes.
>
> Any philosophical thoughts regarding this issue in general?
>
> Specifically, we use a Gauntlet Box.
> We would like feedback if possible.
>
> Regards...
************************************************************
THE RESPONSES WERE :
************************************************************My old company
had a few such requests. The answer was "no". What
we did was allow a few vendors dial in access to only the machine(s)
that we allowed them on. With some kind of password protected
Network Terminal Server inbetween your computer and the phone line,
this, as insecure as it is, is far more secure than allowing them
to come in over the Internet, IMHO. Besides, the telephone bills
will disuade them from coming in any more than is necessary (presuming
it's long distance). Lastly, many rack mounted modems have a "busy"
switch to give out a busy signal; you leave the modem they use in
the "busy" position unless you are having them dial in. This will
keep out the curious who dial every number in the area code looking
for modems (let's face it, today they are probably pinging IP
addresses, not dialing telephones). Another option is to leave the
modem unplugged when not in use, or turn the power off, etc. If
you trust your system administrators to faithfully shut it down
when not in use, you can even put the modem somewhere that they
have access to so that they don't have to bug you to flip the
busy switch for them.
Garry
Garry .
Garrett @
abii .
com
______________________
My personal recommendation for your situation is to have a modem connected to
a terminal server, where the modem connection is disconnected when there is
no reason for the connection, IF YOU WANT TO ALLOW FOR ANY VENDOR ACCESS.
Unfortunately, difficult maintenance is a part of security, because
maintenance
people usually require superuser privileges. I would strongly recommend that
your admins be forced to live with the situation, but that is solely from a
security perspective. Allowing the modem connection facilitates a somewhat
secure connection, that is easily monitored. However, it can be social
engineered to give a hacker access. Perhaps an alternative is to have you be
the person that monitors the connection, but that would cause you a lot of
work.
Talk to you later,
Ira
______________________
Non-authoritative response:
How much do you trust your vendors and technical support people?
Do they have the same understanding of your security policy as your
employees?
Do you run the same background checks on vendors and support people as you do
on
your own employees?
Do your vendors and technical support people have the same loyalty to your
company as your employees do?
Is your internal security (security on individual network nodes) tight enough
to
deny access to unauthorized users on each and _every_ node on your network?
Are you sure, especially for machines which have entries in other machines'
.rhosts or hosts.equiv files?
Once you have answered the above (obvious?) questions, put a value on the
data
and resources exposed on your internal network. Then, ask yourself if the
value
of the data and resources is higher than the cost of _not_ letting vendors
and
technical support people through your firewall and onto your internal
network.
Personally, my employer has flatly stated that there will be no intentional
access to our internal network through our firewall. All access to internal
systems must be through a dialup using one-time access tokens.
dharris @
kcp .
com
Delmer D. Harris
______________________
How you handle this _type_ of request should be something covered by your
security policy. If it isn't, it needs to be added. That being said, there
may be case-by-case exceptions. One approach to vendors that want to provide
information/files electronicly is to have them provide access to THEIR
servers and the appropriate people at your site can do an inside initiated
telnet or FTP to them. I would really hesitate to provide your SecureId
card to anyone that your organization does not have "administrative control"
over, i.e. you can't fire a vendor since they are not your employee.
**** cjolley @
iac .
net <Carl Jolley>
______________________
Hi, whithout knowing more about your specific situation I would think the
answer is no. If in fact they are troubleshooting they would be moving info
that describes your internal network and maybe protential weaknesses. I
make it a habit to inform my clients _not_ to permit any security analysis
of their network via the internet for this reason. If there is a need for
vendors to access your internal net I suggest a dial-up account that you can
enable and disable at will. I would also question why a sysadmin is willing
to let venders muck about on their network.
msk
e-mail @ kadrich @
uni .
ins .
com
______________________
There are many ways to skin a cat. For instance:
We do not allow our vendors access through the firewall. Instead, we allow
them
to dial in, through our dial security system, to the specific machine that
they
need to access.
______________________
Authentication and acknowledgement of the request from both parties,
by each party, involved would be a good start.
Why not use SecureId ? If you've given the vendor one, it's their job to
manage it in a suitable way for responding to your support calls. If they
end up with a cabinet full of those cards, that's their problem, not yours
:)
I'd be very wary of such requests though...
"hi, I'm trying to login to your firewall to get through to abc for xyz and
it doesn't seem to work yet..."
...opens up lots of scope for possible social engineering tricks.
darren reed
______________________
>Any philosophical thoughts regarding this issue in general?
Yes, set up a bastion host and don't let vendors into your internal net.
See the Zwicky and Chapman book.
Steve Simmons
______________________
If you have a tech regularly getting in, give them a secureID card. If
it's someone different, or different vendors, have them call *you* (or
some trusted party) to get a number off *your* card. Card never goes to
vendor.
David Miller
______________________
How you handle this _type_ of request should be something covered by your
security policy. If it isn't, it needs to be added. That being said, there
may be case-by-case exceptions. One approach to vendors that want to provide
information/files electronicly is to have them provide access to THEIR
servers and the appropriate people at your site can do an inside initiated
telnet or FTP to them. I would really hesitate to provide your SecureId
card to anyone that your organization does not have "administrative control"
over, i.e. you can't fire a vendor since they are not your employee.
**** cjolley @
iac .
net <Carl Jolley>
______________________
I would NEVER allow outside vendors to access my network unless they
are physically inside my facility, behind my security.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-
W.S. "Skip" Harborth
Manager & Senior Engineer
Information Systems Security
Engineering
Houston Associates, Incorporated
4601 North Fairfax Dr, Suite 1001
Arlington, Virginia 22203 USA
(703) 284-8732 812-5099 (fax)
sharborth @
hai-net .
com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-
______________________
Philosophically, you ask?
Don't do it. There are plenty of other methods that can be used.
Why not? say the vendors.
Because, ultimately, you can not trust the vendor to have _your_ best
interest
at heart (no matter how much $$$ your throw their way), but _their_ best
interest. And that probably does not include ensuring that your network
and information security policies are followed, and so on.
If they need to shoot problems or provide support, 28.8 modems work fine.
It is not as sexy as doing it over the net, or whatever. But dial up
(especially if the modem is disconnected from the phone line between
calls...which means that the vendor has to alert the customer when they
need access...not just call in anytime...) has been working quite well
for a long time, and, I think, will continue to be so.
Yes, it is a *bit* more cumbersome. So is running a SEAL or Gauntlet or
whatever. But, there accountability and control.
Just my $.02.
--
Bryan D. Boyle | EMAIL: bdboyle @
erenj .
com
______________________
Non-authoritative response:
How much do you trust your vendors and technical support people?
Do they have the same understanding of your security policy as your
employees?
Do you run the same background checks on vendors and support people as you do
on
your own employees?
Do your vendors and technical support people have the same loyalty to your
company as your employees do?
Is your internal security (security on individual network nodes) tight enough
to
deny access to unauthorized users on each and _every_ node on your network?
Are you sure, especially for machines which have entries in other machines'
.rhosts or hosts.equiv files?
Once you have answered the above (obvious?) questions, put a value on the
data
and resources exposed on your internal network. Then, ask yourself if the
value
of the data and resources is higher than the cost of _not_ letting vendors
and
technical support people through your firewall and onto your internal
network.
Personally, my employer has flatly stated that there will be no intentional
access to our internal network through our firewall. All access to internal
systems must be through a dialup using one-time access tokens.
dharris @
kcp .
com
Delmer D. Harris
______________________
My old company had a few such requests. The answer was "no". What
we did was allow a few vendors dial in access to only the machine(s)
that we allowed them on. With some kind of password protected
Network Terminal Server inbetween your computer and the phone line,
this, as insecure as it is, is far more secure than allowing them
to come in over the Internet, IMHO. Besides, the telephone bills
will disuade them from coming in any more than is necessary (presuming
it's long distance). Lastly, many rack mounted modems have a "busy"
switch to give out a busy signal; you leave the modem they use in
the "busy" position unless you are having them dial in. This will
keep out the curious who dial every number in the area code looking
for modems (let's face it, today they are probably pinging IP
addresses, not dialing telephones). Another option is to leave the
modem unplugged when not in use, or turn the power off, etc. If
you trust your system administrators to faithfully shut it down
when not in use, you can even put the modem somewhere that they
have access to so that they don't have to bug you to flip the
busy switch for them.
Garry
Garry .
Garrett @
abii .
com
______________________
For the type of access needed, TCP/IP access to the systems seems very
dangerous to me and I don't see why it would be needed.
Vendor remote connection support can be very useful and even vital, but
firewall or no firewall vender reps. shouldn't be blindly trusted. Here
at JMU the Digital, TGV, and other vendors connect to our system whenever
there is a major problem, but...
The vendors connect via the support modem and new accounts/passwords are
issued for each session. The modem connection requires multiple passwords
and is normally only used by one person, so it's easy to track usage in
the log files.
The actual session is duplicated on the system administrators workstation
so that she can watch everything (and interrupt the session if needed).
She also normally talks to the support rep. on the phone most (if not
all) of the time they are connected to the system.
Vendor support reps can crash a system and do other damage that have
nothing to do with networks and security. We learned that the hard way.
Modem dial-up and single session passwords along with a human monitoring
the session should provide sufficient security. I don't think that the
convenience of TCP/IP over dial-up terminal access makes it worth the
enhanced dangers.
Charles Cooley
Network Services
James Madison University
_________________________________
If access of this type is unavoidable, you may want to consider using dial up
access on a selective basis, via a terminal server with the equivalent of
TACACS or RADIUS support.
Paul Ferguson
_________________________________
There are many ways to skin a cat. For instance:
We do not allow our vendors access through the firewall. Instead, we allow
them
to dial in, through our dial security system, to the specific machine that
they
need to access.
uunet!itthartford.com!pwright
_________________________________
Yalda:
We provided a mechanism to do the following:
1. Require someone at "company name" (I'll say) to turn on the ability for a
vendor
to connect, authenticate, and connect to one inside machine, determined by
the person at "company name" and based on the problem.
2. Have a time limit on this connection (I think... I could be wrong on
this).
3. Have this only work once. If the vendor needed to reconnect, "our company"
would
have to reset things.
We provided a management screen to allow this to be done easily by "company
name"
when a trouble call was logged with a vendor and the vendor indicated access
was needed.
Yes, one time password mechanisms were used (SecurID, SNK cards, etc.).
Fred Avolio
_________________________________
I like to set up a S/Key password, and tell them the next one-time pass
phrase over the telephone for that session.
Peter Da Silva
_________________________________
How you handle this _type_ of request should be something covered by your
security policy. If it isn't, it needs to be added. That being said, there
may be case-by-case exceptions. One approach to vendors that want to provide
information/files electronicly is to have them provide access to THEIR
servers and the appropriate people at your site can do an inside initiated
telnet or FTP to them. I would really hesitate to provide your SecureId
card to anyone that your organization does not have "administrative control"
over, i.e. you can't fire a vendor since they are not your employee.
Carl Jolley
_________________________________
Sorry if I missed someones comments... There were so many.
|
|
