Re: VPN service -- Quick Poll (VPN Alternatives)

[Gary Flynn <flynngn () JMU EDU>]

Here are two other unmitigated risks to consider associated with an
untrusted device accessing sensitive resources through a terminal
services environment:

1) Direct interactive control of a session through BOT/remote
    control malware.

2) Download of sensitive data through file transfer and clipboard
    features of the terminal services environment.

Credential stealing risks can be mitigated by using 2-factor authentication.
File transfers and clipboard functionality can be limited with terminal
services configurations reducing risk associated with local storage
of sensitive data and unauthorized transfer....if your use cases will
allow you to set up such a restrictive environment.

But with an untrusted device, risks associated with screen scraping
and interactive control by unauthorized parties remain.

A properly configured terminal services environment protected with
two factor authentication adds a significant extra layer of defensive
hurdles between an untrusted device and sensitive resources that
may be adequate to bring risk down to an acceptable level for run of
the mill malware and attackers and moderately sensitive data. But
when sophisticated, motivated attackers and/or highly sensitive,
attractive data is involved I think the problem (i.e. the untrusted
device) has to be addressed directly through strict configuration
controls and policies to attempt to retain device integrity. That
costs money, operational time, and practically, limitations on the
devices that can be adequately supported with consistent policies.
Not particularly popular in an era of "consumerization".


To answer the original questions:

1) yes
2) We're migrating from Cisco 3000 series IPSEC VPN to a Juniper SSLVPN
     supporting clientless web, RDP/SSH proxy client,  and IPSEC Network
     Connect clients.
3) We have a 500 user license for our Juniper SSLVPN
4) Access is granted primarily by coarse LDAP based roles with a few
    specialized one-offs handled manually.
5) Yes
6) Our Cisco VPN client was configured to disable split tunneling in the belief
    that the extra traffic through our internet connection is not consequential
    enough to accept risks associated with a client possibly bridging the campus
    and the home network. There was also some thought that campus security
    measures also slightly decreased risk when all internet traffic was funneled
    through the campus internet connection (e.g. dns blackhole, IPS, inbound
    blocks). Though that occasionally results in an RIAA notification for a home
    computer, it is rare enough that it has not been sufficient motivation to change.

Sam Hooker wrote:
> On 20120312 10:28 , Gramke, Jim wrote:
> > For many years, we've been using citrix as our remote access tool.
> > Although from the beginning this happened mostly by accident, I
> > like the solution because this way, applications and sensitive data
> > aren't exposed to the home machine, which, from a security perspective
> > is an unknown quantity.
> >
> > I've always been a little leary to allow any home machine the direct
> > access to sensitive apps and data that VPN provides, not to mention
> > exposing the school's network directly to these home machines.
> > Or are my fears unfounded, and I'm just missing something basic about
> > the features and controls vpn's have?
> While a fan of "the hosted desktop" for a number of reasons, I'll note
> that it doesn't mitigate against all threats to the endpoint --
> keyloggers running on the user's home machine probably capture
> keystrokes bound for the Citrix client as well as any other. Depending
> upon what gets saved in the client's login dialog, this could lead to an
> enticing-looking string of entries in a keylog. I perk up when I find a
> text file with lines like
>
> ...
> citrix.uvm.edu
> sthooker
> h0lym0ly1'ml33t
> ...
>
> Although I haven't looked for any such thing specifically, I'd be
> surprised if there *weren't* malware designed to at least screen-scrape
> the Citrix and MS RDP clients -- and wonder if there's any practical
> countermeasure against such a technique.
>
>
> Cheers,
>
> -sth
>
> --
> Sam Hooker |samuel.hooker () uvm edu
> Systems Architecture and Administration
> Enterprise Technology Services
> The University of Vermont
>
> > -----Original Message-----
> > From: Dave Koontz [mailto:dkoontz () MBC EDU]
> > Sent: Friday, March 09, 2012 6:56 PM
> > Subject: Re: VPN service -- Quick Poll (split tunneling?)
> >
> > This topic is always a lively discussion!  ;-)   But I believe the
> > conversations of old may need to be re-examined with today's technology options in mind.
> >
> > First disclosure, we only allow supervisor approved access to our VPN for our users, and only on institutionally owned 
> > machines.  A fall back for a pandemic or other emergency is in place where those rules change.
> >
> > Like many of you, we ran Cisco VPN concentrators for years and forced our remote users through our limited bandwidth 
> > pipe whenever they needed a campus resource, and ALL traffic came through our pipe for security reasons.  Since we did 
> > not allow split tunneling, our remote office users could not even do simple things print to their local printers from 
> > our ERP system.
> >
> > We have recently upgraded our systems to use the Palo Alto SSLVPN / Global Protect Client.  This is generally setup as 
> > a purely SSL VPN, but can also act as a Cisco Style IPSec VPN for site to site VPN Tunnels, or setups on iPads and the 
> > like.
> >
> > So, we have moved away from not allowing split tunneling to embracing it
> > - with proper control and network access  limitations.  With Palo Alto we can determine which traffic we allow into our 
> > core, and all others are blocked.  And even the traffic that comes into our core must pass the IPS rules to ensure that 
> > the safe traffic safe.
> >
> > It's always a delicant balance to enable users, yet protect our networks.  I believe modern technology can give you that 
> > balance, if properly configured.  Don't ask a 10 year old product to try to do this.
> >
> >
> > On 3/9/2012 3:25 PM, Kris Monroe wrote:
> > > For those that have answered yes, would you mind outlining whether you
> > > allow split tunneling or not? I would also appreciate your rationale
> > > one way or the other.
> > >
> > > I've always been taught that split tunneling is a really bad idea, but
> > > this topic has recently come up in our remote access project.
> > >
> > > --
> > > Kris Monroe, CISSP, CISA, CISM
> > > Information Security Officer
> > > Office of Information Technology Services Job Hall
> > >
> > > Ithaca College
> > > 953 Danby Rd. | Ithaca, NY 14850
> > > 607.274.1997 | 607.274.1484 fax
> > > kmonroe () ithaca edu  | ithaca.edu
> > > Follow us: facebook.com/ICInfosec | twitter.com/IC_infosec
> > >
> > > On 3/9/2012 9:18 AM, Zahid Mehmood wrote:
> > > > Hi All,
> > > >
> > > > Quick Poll Please:
> > > >
> > > > 1.      Is your campus using, or does it plan to use,  VPN access for remote users?
> > > > 2 .     What vendor(s) and protocols (SSL, IPSec, other) are you using?
> > > > 3.      How many concurrent remote users can your system support?
> > > > 4.      Do you offer any specialized/custom VPN services for departments, researchers, etc.?
> > > > 5.      Is your VPN offering part of your DR plan/requirement?
> > > >
> > > > Thanks!
> > > >
> > > > Zahid Mehmood
> > > > Network Software and IT Enablement Systems Columbia University
> > > > Information Technology


--
Gary Flynn
Security Engineer
James Madison University

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature