Re: Where do you stand? --- University policy on Jail broken mobile device access to secure networks.

[Eme Ejike <eejike () ODU EDU>]

> So, let's assume we want to prohibit these devices on the network, or even just certain (ie "secure" networks).  I've been 
> thinking about it, and other than visual inspections, I'm not sure how you could do this.  Policies are easy.  Enforcement .. not so much.  
> Thoughts?
 As part of the on-boarding approach for BYOD, users would authorize 
the installation of an MDM app. The view is; You pay to play!.
We however intend to minimized all monitoring capabilities of the MDM 
app to the barest minimum.
A proposed approach would be to have the MDM  solution identify these 
users and the corresponding device running under a J.B environment.
In a scenario where certificates are in use for authentication (i.e 
eap-tls for wireless) to the necessary network segment  a revocation of 
said certificate simply denies access. Since certificates are issued on 
a per device certificate model we would avoid impacting services to 
other sanctioned devices owned by the same user.
It looks like our focus is mainly on mobile devices but as we all know 
this includes laptops, tablets and the likes. A NAC solution also comes 
into play for patch levels, etc......but I digress.
The overal objective is to be able to define the appropriate pay to play 
standards for BYOD integration; with a limited scope might I add; with 
the university business functions.


--
Eme


On 03/29/2012 04:46 PM, Brian Helman wrote:
> I think your last statement says it all.  There is that (false?) sense of security from Apple, but let's compare that to 
> Microsoft's security model.  *cough*.  In the end, I wonder if there is anything we can do (or care to do) about the 
> end-device rather than handling security at a network level.
>
> As far as SSH, I remember under 4.x there was a tweak that allowed you to prevent the SSH server from auto starting.  As far as 
> I've seen, under 5.x it doesn't exist.  I reboot my JB 5.x devices far less than I did under 4, but I need to remember 
> to turn off the SSH service.
>
> So, let's assume we want to prohibit these devices on the network, or even just certain (ie "secure" networks).  I've been 
> thinking about it, and other than visual inspections, I'm not sure how you could do this.  Policies are easy.  Enforcement .. not so much.  
> Thoughts?
>
> -Brian
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John Ives
> Sent: Thursday, March 29, 2012 2:11 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Where do you stand? --- University policy on Jail broken mobile device access to secure 
> networks.
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 3/29/2012 10:24 AM, Brian Helman wrote:
> > Absolutely.  Just as a laptop with a poor Administrator password is a
> > liability, a JB device with the default/poor password would be as
> > well.  I don't recall if the SSH service is installed as a part of the
> > JB process or not.  But you do have far easier control of the services
> > (from a user standpoint) than stock.
> It would probably depend upon the jailbreak method, but I can tell you that usually it is. In fact I have a jailbroke 
> ipad on my desk now running ssh and waiting to get compromised because I want to see what happens (think of it as a 
> portable honeypot).
>
> > This discussion is tangential to the BYOD discussion.  Do you let
> > those devices access your secure network or not?  I can tell you, in
> > some ways my JB devices are more secure than when they weren't
> > -- because I can lock applications individually and change files to
> > read-only.
> But the ones that are more secure is a very small portion of the jailbroken population. We see jailbroken iOS devices 
> regularly getting hacked and being used to attack others. In contrast I have only seen a couple androids attack others.
>
> > And honestly, I strongly believe a jbroken iOS device is still more
> > secure than a stock Android device, as long as you only use the stock
> > Cydia repos.  There are definitely some questionable repos out there
> > that would rival the Google app store.
> Not to start a religious war, but I disagree with this.  I have spent a bit of time working with androids (both rooted and 
> stock) and feel their security is, just like other devices, an issue of how they are used.  Yes, there have been instances 
> of malware getting into the google market, but its not really that common and again it is based upon decisions made by the 
> user.  I personally, on my androids, get most of my apps from Amazon who has a testing policy to ensure security.  The only 
> ones I don't get from Amazon are either by major vendors (adobe for instance), or are specific to computer security in 
> which case they go on devices intended for such work.
>
> My household has 4 android devices (2 rooted) and 3 iOS (1 jailbroken), so I have some experience comparing them. For 
> me the breakdown is that out of the box and for normal work, iOS is more secure than android (how much more secure is 
> an issue of the user).
> Once rooted/jailbroken, that model is reversed with the androids (depending upon the method used) becoming more secure and the 
> iOS less. The difference is that a rooted android, if you replace the ROM, tends to remove superfluous software and doesn't 
> start new services, while the jailbroken iOS adds new network services and doesn't warn a user to secure them so when we see 
> compromised devices they are almost always iOS, and generally attacking others.
>
> Ultimately, what has made the iOS (stock) more secure is Apple's decision to be the arbiter of what can be installed.
>
> Yours,
>
> John
>
> - --
> - -------------------------------------------------------------------------
> John Ives
> System&  Network Security                       Phone (510) 229-8676
> University of California, Berkeley
> - -------------------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPdKWZAAoJEJkidK6qbywsjlgIAI8OxrI9Dmbl4SN4jAKwz9VF
> WDWUiIv01ig/mDbWD+xbyflY/vt6IQ/PezB7076YWHER+S4Yir+5fkK814ZpE/Wh
> OAYuJwyRxXJEB2+DREzEOX9rIIYetm+qWxUbpfcJH6DYLXvqVw8CqJjJfs42Q3zN
> Kr5kVU8Kozy2rltUikh9JdUO4C2xfx4uCyBInlSQK0CIlkksSktNxfETzMMs1LjE
> ObO44Djz/bGfj9x/1SqHPrmD2QN9RmE2bNRjqZjOc/16wTR68jlq73w5PvQuS3Zx
> zT+z33QUrEN5AcesXlQX9NZHhcLqTXwSFIyRTGLIvyEburShBIE0yyZw5fcvoJ4=
> =NIm+
> -----END PGP SIGNATURE-----