Re: Remote access and data offloads.

[Steve Brukbacher <sab2 () UWM EDU>]

One of our challenges is in this area is in developing a process for
ensuring that the remote access is removed if an employee is
fired/quits.  Often times in acadamia we see people keeping their
central ID for quite a while after they leave.  I'm trying to develop a
process where we'd make sure of two things:

1. The employees supervisor is aware that they are getting remote
access. If an admin assistant wants remote access to work from home, is
this okay with the supervisor?
2. That they remember they gave it to them if they leave the
department/university.

For us this will mean some sort of sign off form/policy statement and a
solid process.

We plan on using VPN to limit RDP to on campus addresses as well.

Still not sure about the drive mapping issue.  We currently block that
at the perimeter and don't want to undo that so SMB ports may not be
available over VPN.  We also offer Xythos which is a nice https file
sharing product.  We'd rather our users do that than map drives from off
campus.

VPN will also be available for folks who want to encrypt their campus
wireless traffic or other off campus wi fi traffic.


--
Steve Brukbacher
University of Wisconsin Milwaukee
Information Security Coordinator
UWM Computer Security Web Site
www.security.uwm.edu
Phone: 414.229.2224



Russell Fulton wrote:
> Chris Green wrote:
>
> > Hey from up I-59 :),
> >
> > I've been trying to address this same problem by trying to make sure that
> > the desktop groups have centralized logging for for failed and successful
> > login.
> >
> > I originally went down the road of wanting to block RDP and force VPN but
> > have since come to the mindset that there's a lot of pros for people to use
> > RDP.
> >
> > Having users university data using their work desktop rather than having
> > their own PC via VPN and working from there gives us more control at the
> > point we really care about.  Originally, our VPN was a customer service
> > issue when @home blocked MS Networking (my things have changed ;-) )  It's
> > also much easier for our helpdesk to walk someone through finding mstsc on
> > their PC than it is for someone to install the VPN client.
>
>
> What we are doing for our critical systems is running rdp on the servers
> with some restriction on which IPs can connect.  We block RDP for these
> servers at the border and get people to use vpn to get on to campus.  We
> are about to set up two factor auth for our vpn and this will dump you
> into a special dhcp pool which and the addresses in this pool will have
> access to the sensitive servers.
>
> And yes we have a project to centralise our windows auth logs to guard
> against brute force attempts.
>
> > A weakness is that it allows brute force attempts against more PCs and local
> > account which is traditionally
> >
> > One line of thought that would move be back towards VPN is the ability to
> > have policy compliance (patch checking, AV up to date, infection free?)
> > performed on the desktop before they connect to the network. All of the
> > products that I've seen for that perform that check AFTER the user has given
> > their credentials away which is the (or one of the) event that was critical
> > to prevent.
>
>
> hence our requirement for 2 factor auth (and yes, I know it is no
> panacea but it helps ;)
>
> Russell