[VPN] Clientless VPN (apologies for the cross-post)

[safieradam]

No, I am not advocating blocking all encrypted traffic.  I strongly disagree
with the brain-dead French government that outlawed strong encryption
several
years back.

I am a big fan of VPN's, including VPN between the client and the
application host.  Personally, I want SSL connections to web sites that ask
for any type of registration information or have private data.  I'm also
very interested in data-tagging, the encryption of portions of a document so
only certain people can access that portion.  All of these are great as long
as you are managing them, they are under your control and fit within your
security policy.

The issue is one of policy enforcement points and monitoring of "general"
traffic.  Many organizations want to check for viruses in incoming traffic
before it reaches the end user.  Some also do content filtering on outbound
and inbound traffic in an attempt to control sharing of secrets.  They
usually have security layers of firewalls and IDS systems.  Host IDS,
firewalls, virus scanning and other security measures add overhead and the
available systems are just starting to emerge.  Please give me a pointer to
a product that can apply content scanning per company policy to outbound
sMime e-mail _on_the_user's_PC_.  Perimeter checkpoints are the most widely
implemented method for dealing with Internet security while the tools to put
a police team in everyone's home are still developing.

True, the GoToMyPC system primarily transmits screens and play nice by
having a fixed server name (now).  But it also has a print and file transfer
capability. If a user connects to their home PC via an encrypted link and
then surfs from there to xxx.hacz.com they have bypassed security controls
that are not loaded directly on the office PC. If the user is at home and
connects to his office PC the screens (i.e. data) can be captured and
forwarded, bypassing content filtering the company may have implemented.
What about competitors that may not be as nice or allow connecting directly
host to host?  Hackers have been encrypting back door connections for years.
The ones we've caught usually used fixed ports and identifiable traffic
patterns.  If everyone is suddenly running encrypted traffic over port 80,
or other ports for that matter, identifying malware becomes an even bigger
hassle than it is today.

What I am saying, in my roundabout way, is that as host to host VPN
technology becomes trivial to load and implement, security policy has to be
reviewed and security architecture questioned.  Do you keep buying IDS and
firewalls or do you reduce the costs of labor intensive network IDS
monitoring and focus on (labor intensive) end user PC and host IDS
monitoring?  What will the transition entail and how long will it take?  In
the mean time, you may wish to do a risk assessment and ban/block encrypted
traffic on certain parts of your organization's network.  Which parts and
which users depends on your security stance and policy.

Adam Safier


----- Original Message -----
From: "Evans, TJ (BearingPoint)" <tjevans at bearingpoint.net>
To: <vpn at lists.shmoo.com>; <win-security at lyris.sunbelt-software.com>
Cc: "safieradam" <safieradam at hotmail.com>
Sent: Thursday, April 17, 2003 6:35 AM
Subject: [VPN] Clientless VPN (apologies for the cross-post)


> If I read your statement(s) correctly -
> You recommend blocking all encrypted traffic?
>
> IMHO - This leaves a few problems unsolved, and creates many new ones!
>
> Unsolved:
> Unencrypted, although possibly still tunneled, traffic.
> (ICMP tunnels, remote command prompt (e.g - NetCat), etc.
> etc.)
>
> Newly Created:
> You would block all SSL'ified websites?
> Block all encrypted mail?
> Etc.
>
> Don't get me wrong - there are ways to mitigate the new problems, but my
> concern would be that I think this would send the wrong message to your
> employees ... and discourage (prevent?) them from following good practices
> (encrypting important client emails, only logging into sites that make use
> of SSL, etc.).
>
> Naturally - the real-world / business needs of your employees may permit
> such an approach ... but I think this would lean too far to one side of
the
> "security vs. functionality/usability" scale for most.
>
>
>
> Thanks!
> TJ
> <PS - don't forget to patch your Win* servers ... *fun* >