Re: Java vs. Banner

["Erlenbeck, Philip" <perlenbe () UMFLINT EDU>]

At first glance the ThinApp appears to be working.  

Going to have a few users put it through some more thorough testing.  We built the app using firefox and java 1.6.41, 
with the BlockSite addon only allowing firefox to talk to our internal domain.

I'll update with any issues if we find any.

--Phil
________________________________________
From: The EDUCAUSE Security Constituent Group Listserv [SECURITY () LISTSERV EDUCAUSE EDU] on behalf of Greg 
Schmalhofer [Greg.Schmalhofer () MILLERSVILLE EDU]
Sent: Thursday, February 21, 2013 2:55 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Java vs. Banner

Any info or user experience that anyone can share regarding running Banner as ThinApp or RemoteApp would be 
appreciated. Phil, please let us know how your testing goes.

Thanks,
Greg

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of 
Erlenbeck, Philip
Sent: Thursday, February 21, 2013 2:29 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Java vs. Banner

Speaking of Virtual, the approach we are testing out is removing Java from the users machine, and providing a ThinApp 
that the users can use for Banner access.

--Phil

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Kevin 
Wilcox
Sent: Thursday, February 21, 2013 1:52 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Java vs. Banner

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 21, 2013 at 06:30:45PM +0000, Ludwig, David C. wrote:

>    We've had some discussions around limiting access to Banner
>    INB from a set of VMs on a specific subnet.  Those machine would be built
>    with IE8, Java 6 etc and would be limited to only access Banner and a
>    handful of other systems on campus (document management for example).
>    Users could then do whatever they needed on their location machines as far
>    as Java/IE upgrades and web browsing.  But the access to Banner could only
>    occur once logged into the a secured VM.

We've had similar discussions but I would like to point something out about your phrasing -- "once logged into the/a 
secured VM".

If you let the physical machine do what it will, and rely on the virtual infrastructure to be the secure component, 
you're going to win the battle with users but lose the war with the bad guys.

Once the physical host is compromised, account credentials typed into the VM are going to be leaked. Screenshots are 
going to be leaked. If it's a sophisticated attacker, he/she will come back and access the virtual environment through 
the compromised workstation.

I would suggest, if you're really able to get buy-in, inverting the model. Allow the physical machine access to your 
on-campus resources and then permit general web use through something like VDI/Citrix/Xen desktops or through a tightly 
controlled content filtering effort (with access policies determined by the business units, NOT mandated by IT, we 
generally don't know what our users really need). A "voluntary" squid cluster to proxy (and filter) http and https is 
*very* cheap -- and certainly cheaper than a compromise in key areas.

I know this is practically impossible to push *everywhere* but if you can get buy-in from sensitive areas and protect 
those key spots, you're already making the environment more difficult to penetrate than your neighbour.

At least, that's what I've heard...

kmw

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlEmbNkACgkQsKMTOtQ3fKGOtQCfTmMSeAyyguX99DfOJgwlh6Wd
HV4AnRXgg7JJPgiUOM4Et6WgNCegVBah
=sc7d
-----END PGP SIGNATURE-----