[prev in list] [next in list] [prev in thread] [next in thread]
List: ntsecurity
Subject: RE: [NTSEC] VPN tunnels to other networks
From: "Robert Schwartz" <robert () mrsquirrel ! com>
Date: 2000-03-06 20:31:25
[Download RAW message or body]
TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net
Contact ntsecurity-owner@iss.net for help with any problems!
---------------------------------------------------------------------------
This is a multi-part message in MIME format.
Basically I look at the situation this way:
1) VPNs for b-to-b transactions will only become more necessary
2) managing 2 sets of applications and keys for every use will only become
more and more useless and time consuming
3) keeping up to date on security patches and crypto compatibility issues
will only become more and more useless and time consuming,
4) the need to keep this data completely secure ON BOTH ENDS (even the end
that you don't control) will become more and more publicized and political.
Therefore:
investing the time and energy now into a VPN tunnel gateway that sits on (or
just inside or just outside) the firewall that uses IPsec standards will pay
off more than any other strategy.
Many firewalls (checkpoint comes to mind immediately for their excellent
support on NT) already support this. You only need to manage ONE crypto
point, not a pair for every transaction. Using just pre-shared keys or
secrets at first will be fine, but eventually you will need PKI. Make sure
your solution is Entrust enabled (not that Entrust is the only player, but
they are the de-facto standard).
Then define a standard for trusting other sites. Only allow the sensitive
material in or out if it is strong crypto using open standard IPSec.
Documenting this now should CYA when some VP starts to scream about this ad
hoc poorly considered plan or that one. Then, if the foreign site has the
minimal requirements, you can allow the tunnel. Just for data, not for net
access though, because (and here's the REALLY scary part about b-to-b) all
of your "partners" machines are probably owned. You have to assume the
"partner" has been so thoroughly hacked that not a single machine is clean,
virus free, and without backdoors.
It is not paranoia if they ARE out to get you.
-----Original Message-----
From: owner-ntsecurity@iss.net [mailto:owner-ntsecurity@iss.net]On Behalf
Of nj
Sent: Tuesday, February 29, 2000 7:14 PM
To: ntsecurity@iss.net
Subject: [NTSEC] VPN tunnels to other networks
I would like to hear feed back on allowing users to set up VPNs using
clients to other networks for legitimate business needs. This is coming up
more and more and before I add another client application to these machines
with connections to networks beyond my control, I would like everyones
opinion. I want to weigh the risk over business needs and your input would
be very beneficial. I do not want to set up separate networks for my users
and unlike most administrators, I can say whether these clients get
connected to these other networks or not.
Thanks in advance. I'll be watching.
nj@kbi.state.ks.us
Norma Jean Schaefer
ITC/ISO
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=302412120-06032000>Basically I look at the situation this
way:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=302412120-06032000>1)
VPNs for b-to-b transactions will only become more necessary</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=302412120-06032000>2) managing 2 sets of applications and keys for
every use will only become more and more useless and time
consuming</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=302412120-06032000>3)
keeping up to date on security patches and crypto compatibility issues will only
become more and more useless and time consuming,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=302412120-06032000>4) the
need to keep this data completely secure ON BOTH ENDS (even the end that you
don't control) will become more and more publicized and
political.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=302412120-06032000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=302412120-06032000>Therefore:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=302412120-06032000>investing the time and energy now into a VPN tunnel
gateway that sits on (or just inside or just outside) the firewall that uses
IPsec standards will pay off more than any other strategy. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=302412120-06032000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=302412120-06032000>Many
firewalls (checkpoint comes to mind immediately for their excellent support on
NT) already support this. You only need to manage ONE crypto point, not a
pair for every transaction. Using just pre-shared keys or secrets at first
will be fine, but eventually you will need PKI. Make sure your solution is
Entrust enabled (not that Entrust is the only player, but they are the de-facto
standard). </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=302412120-06032000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=302412120-06032000>Then
define a standard for trusting other sites. Only allow the sensitive
material in or out if it is strong crypto using open standard IPSec.
Documenting this now should CYA when some VP starts to scream about this ad hoc
poorly considered plan or that one. Then, if the foreign site has the
minimal requirements, you can allow the tunnel. Just for data, not for net
access though, because (and here's the REALLY scary part about b-to-b) all of
your "partners" machines are probably owned. You have to assume the
"partner" has been so thoroughly hacked that not a single machine is clean,
virus free, and without backdoors. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=302412120-06032000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=302412120-06032000>It is
not paranoia if they ARE out to get you.</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> owner-ntsecurity@iss.net
[mailto:owner-ntsecurity@iss.net]<B>On Behalf Of </B>nj<BR><B>Sent:</B>
Tuesday, February 29, 2000 7:14 PM<BR><B>To:</B>
ntsecurity@iss.net<BR><B>Subject:</B> [NTSEC] VPN tunnels to other
networks<BR><BR></DIV></FONT>
<DIV>
<DIV><FONT size=2>I would like to hear feed back on allowing users to set up
VPNs using clients to other networks for legitimate business
needs. This is coming up more and more and before I add another
client application to these machines with connections to networks beyond my
control, I would like everyones opinion. I want to weigh the risk over
business needs and your input would be very beneficial. I do not
want to set up separate networks for my users and unlike most administrators,
I can say whether these clients get connected to these other networks or
not.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Thanks in advance. I'll be watching.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2><A
href="mailto:nj@kbi.state.ks.us">nj@kbi.state.ks.us</A></FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Norma Jean Schaefer</FONT></DIV>
<DIV><FONT size=2>ITC/ISO</FONT></DIV></DIV></BLOCKQUOTE></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic