On Thu, 7 Jun 2001 [EMAIL PROTECTED] wrote:
> > The problem is that everyone seems to _require_ HTTP/HTTPS access these
> > days, so there's your trojan's control vector happily provided either
> > directly, or via the corporate firewall.
>
> And this is different from an on-site user, visiting the web
> through the corporate firewall, exactly HOW? i.e. I do not see how
It's not, hence the words "or via the corporate firewall."
> this risk is exacerbated if the client connection comes across a VPN
> tunnel rather than just a length of Cat5.
If you're not piping Internet access through the corporte firewall, you
lose the log analysis, NIDS and inspection vectors that are the last line
of defense.
Also, in the remote node case, I've yet to meet anyone who wouldn't let me
install something on a PC at home, corporate or not, but I've met a few
people who wouldn't let me into their office.
Remote application access is significantly easier to control and assure
than remote network access. Security should be about making things
better, not just bad in different ways.
> [Consider also the case of the travelling employee who, after a
> stint on the road, plugs his laptop into the internal net. No amount
> of filtering at the tunnel endpoint is going to address this
> analogous real-world case where a machine is sometimes connected to
> the internal net, and sometimes not.]
Right, the difference is that you're dealing with store and forward
intrustion versus real-time intrusion in that case. But user traning and
policy should cover the absent laptop case, which should also deal with
access control on the laptop. 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.
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.
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.]
