On Thu, 7 Jun 2001 [EMAIL PROTECTED] wrote:
> > It's not, hence the words "or via the corporate firewall."
>
> If it's not, then the VPN is not a relevant part of the risk
> scenario you're presenting. If the vulnerability is in allowing
> machines on the trusted network to browse the web, then that's all
> that's needed to define the scenario.
As was the case in the article I wrote which started this thread.
We went from that generic to discussing more specific scenerios.
> > Right, the difference is that you're dealing with store and forward
> > intrustion versus real-time intrusion in that case.
>
> If the VPN tunnel cuts off all other access -- as it does in the
> clients I've deployed -- then the VPN case is *also* strictly store-
> and-forward. THAT is whay I called this case "analogous". Again,
> I'm trying to grasp what features of your scenario are relevant, and
> what are not.
In this message you're talking about cutting off all other access, and in
another you're talking about giving more access- this paints a
discongruous picture. I once again submit that it's difficult to cut off
all other access in today's business environment, and more pointedly that
strong per-application access is still a much more assurable soltuion than
VPNs.
> > .... If said laptop is only used to directly dial the corporate
> > network, it's a signifcantly lower risk than if it's plugging into
> > Ethernet jacks in hotel rooms.
>
> You've lost me here. (a) Running a modem pool securely has always
> seemed to me like *more* of a security challenge than a VPN, not
> less, and (b) I can write any such policy I like, but how do I
> monitor compliance, short of assigning each mobile user a chaperone?
On the laptop end, it's a lower risk because the machine is on a switched
circuit where the control is out of band and the level of assurance is
higher. On an Ethernet jack in a hotel, it's potentially shared media,
untrusted DNS, untrusted MITM proxy servers...
Compliance is relatively easy to enforce on some architectures, and more
difficult on others. Certainly you can make it so that the user has to
knowingly violate the policy prior to connecting to an untrusted network.
> > Again, if you go with application access, then that works on the
> > local net as well, making it easier to place less trust on internal
> > clients as well.
>
> I suppose that if I only ever had clients and servers, I could put
> all of each class in a separate subnet/VLAN and filter/NIDS/firewall
> them at the router connection. That doesn't play very well in a peer-
> to-peer world, does it?
Despite the trade press' insistance to the contrary, there's very little
peer to peer traffic on most networks, and that which is, normally isn't
part of the business' critical function due to the challenges of doing
backup and disaster recovery. Handling exceptions as exceptions is much
more preferable from an assurance standpoint than architecting for the
exceptions and taking all the baggage that entails for the generic case.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
