android/iphone on the corporate network

[Dr. Xing]

What's the trend/feelings/policies you are seeing with regards to allowing Android devices (phones/tablets), iPhones, iPads, etc. onto the corporate network?

Our stance right now is "no" until we can figure out what to do and come up with policy. Since we are getting more and more push from the users about it, we need to figure that out soon.

 

[royd]

We have setup a seperate network for internet access as this is mostly what people need/want. Some of the devices support VPN clients but that could be messy

 

[randomdude]

We have allowed users with iPad's to use Cisco AnyConnect to VPN in to the company's network to run a few applications on some internal servers. While I was not especially keen on doing so once you present your concerns to the upper management if they want it they will get it and we have had no issues*knock on wood* with them doing so.

 

[XOcet]

With us, they all sit outside the corporate network, and have to connect via a VPN to access any non-internet facing services. In other words, just like any other device accessing the network externally/

To use internal apps, they need to connect to a virtual desktop, so data is not stored on the device. Corporate devices use mobile device management software to enforce password and encryption policies, and provide remote wipe.

If you are to allow these devices access to internal applications, and thereby allow them to store data locally, you need to have some sort of mobile device management capability to ensure you can enforce passwords, encryption, remote wipe, etc. Virtual desktops can play an important role in providing the necessary access, and may in fact be necessary depending on the sort of applications a user needs access to, and can help mitigate security concerns.

You do need to work out how to support these devices on your terms. If you don't, users (especially more senior members of the organisation....) will work out ways themselves.

 

[xcrunner529]

you need to have some sort of mobile device management capability to ensure you can enforce passwords, encryption, remote wipe

Exchange 2010 includes all that for any devices adding their Exchange account.

 

[Dr. Xing]

Yes, VPN and ACLs is an obvious choice. But I've already heard "Why do I have to do that? My device has WiFi, why can't I just connect to the WiFi?"

 

[scorp508]

"Why do I have to do that? My device has WiFi, why can't I just connect to the WiFi?"

Were the devices security reviewed, approved, and purchased by the IT department or did the users just start showing up with them?

 

[hutchingsp]

"Why do I have to do that? My device has WiFi, why can't I just connect to the WiFi?"

Were the devices security reviewed, approved, and purchased by the IT department or did the users just start showing up with them?

I think one of the issues these days is that as an IT department, if you need to buy devices that sync email, usually those devices are capable of doing much more.

That's not the same as saying you want them to be used to do many of those things, IYSWIM.

 

[scorp508]

"Why do I have to do that? My device has WiFi, why can't I just connect to the WiFi?"

Were the devices security reviewed, approved, and purchased by the IT department or did the users just start showing up with them?

I think one of the issues these days is that as an IT department, if you need to buy devices that sync email, usually those devices are capable of doing much more.

That's not the same as saying you want them to be used to do many of those things, IYSWIM.

I agree entirely. Having a well documented "If you show up with your own device we will or won't XYZ....." policy in advance can greatly help.

 

[Devin]

Personal devices in my org are specifically prohibited from being connected to the network, so there is no real concern here.

 

[SandyTech]

Because of PCI-DSS requirements, we don't have a wireless network at all and have no plans to change that fact. We may be told from on high to change that soon (our new GM is an enormous PITA).

Other places I've worked have had varying rules. One, a medical office, provided an internal, hidden SSID wifi network for their own use that had 802.1x to make sure that only the doc's laptops connected to it (they used a full EMR setup, which was *very* cool). After getting some requests, we added an air-gapped WiFi AP for personal devices and people in the waiting room.

Their policy was that only company issued tablet PCs/laptops were allowed onto the internal wireless network, no ifs ands or buts about it. If they wanted to browse the web or check the scores or whatever, they could connect to the waiting room router, FSM knwos that little EnGenius WAP put out enough power for them to.

 

[Dilbert]

Personal devices in my org are specifically prohibited from being connected to the network, so there is no real concern here.

Prohibited or blocked? If it's prohibited it won't stop people from trying. Plenty of arrogant execs will just bring their personal iPads and may even bully the helpdesk staff into assisting with the config. On the flip side there are plenty of office workers who have never read the company policies and are completely clueless about computer security. It never would have occured to them that bringing a personal device might be something that's frowned upon.

Require 2-factor auth for the wireless. Always. 802.1x (domain user and machine auth) with RADIUS/IAS.

Then setup a separate guest wireless network, give it direct internet access with no route back to your LAN, give the IT helpdesk and the receptionist the ability to authorize time-limited access to the guest wireless, and off ya go. 99 out of a 100 times someone plugs into your LAN they just want Internet access.

 

[xcrunner529]

One, a medical office, provided an internal, hidden SSID wifi network for their own use that had 802.1x to make sure that only the doc's laptops connected to it

You're breaking the spec doing that and just asking for problems down the road.

 

[Dilbert]

^^ Besides that's kind of like camouflaging a door that can't be broken into.

Use AES and WPA2. Done. Let the SSID broadcast.

Besides WLANs with hidden SSIDs can still be detected. Whether or not they are detectable is not up to you. It is entirely up to the wireless client and their wifi adapter/drivers. Apple client will hide your WLAN but a l33t hacker on his Linux box will see it. Which of these two hypothetical clients is likely to try to hack in? Also, capturing wireless frames does not require SSID association at all.

 

[Devin]

Personal devices in my org are specifically prohibited from being connected to the network, so there is no real concern here.

Prohibited or blocked? If it's prohibited it won't stop people from trying. Plenty of arrogant execs will just bring their personal iPads and may even bully the helpdesk staff into assisting with the config. On the flip side there are plenty of office workers who have never read the company policies and are completely clueless about computer security. It never would have occured to them that bringing a personal device might be something that's frowned upon.

Require 2-factor auth for the wireless. Always. 802.1x (domain user and machine auth) with RADIUS/IAS.

Then setup a separate guest wireless network, give it direct internet access with no route back to your LAN, give the IT helpdesk and the receptionist the ability to authorize time-limited access to the guest wireless, and off ya go. 99 out of a 100 times someone plugs into your LAN they just want Internet access.

No wireless yet, but looking at an Aruba system next year, which I believe will require a fob with a cert.

No BES, no hotsync: tecnically we allow corporate owned devices to be plugged in and synched with desktop software, but nothing goes OTA. Sad, I'm not even allowed OTA email on my corporate devices...

 

[Uhlek]

No BES, no hotsync: tecnically we allow corporate owned devices to be plugged in and synched with desktop software, but nothing goes OTA. Sad, I'm not even allowed OTA email on my corporate devices...

It blows my mind when companies keep their heads in their sand like that.

 

[Signal Chaser 76]

We've pretty much decided that the consumerization of IT is a battle that was lost a few years ago, so we let just about any device on our network.

This leads to many headaches, but on the balance, allows our employees to use what they like. And it's freed us from BES.

All that said, Android has been the biggest pain in the ass. Not only do I have to worry about the Android OS versions, but also HTC's, Samsung's and Moto's mail applications. FOr instance- a few of our users have a T-Mobile myTouch 4g. Until just last week, you couldn't send emails using it with Exchange 2010 active sync. This is an acknowledged bug in HTC's mail app. Virgin Android phones and other manufacturers work fine.

And just before that, I put in a hardware load balancer in front of our Exchange CAS servers. The LB also does SSL processing. Every phone in our network, from iPhones to my WebOS device to even old Nokias handled the intermediate SSL cert correctly. But Moto and Samsung mail clients include an extra "Verify SSL" check box. We had to re-initialize email on about 20 Moto & Samsung android devices. HTC's weren't affected.

 

[XOcet]

We've pretty much decided that the consumerization of IT is a battle that was lost a few years ago, so we let just about any device on our network.

This leads to many headaches, but on the balance, allows our employees to use what they like. And it's freed us from BES.

All that said, Android has been the biggest pain in the ass.....

You could "recommend" or only support users if they connect through something like TouchDown. This at least provides consistency across versions and vendors. Yes, it costs money, but it'd probably still work out cheaper in the end.

 

[RRLSi]

Deployed Airwatch. It's a nice product.