Network Evolution

Building the infrastructure for the changing face of IT


Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Networking for BYOD: No single solution

An architecture firm IT manager finds himself mitigating the risks of BYOD after he realizes there is no easy answer to managing and securing personal devices on the network.

Leo Pickford, IT manager of ArchitecturePLB in London, learned two things about a bring your own device (BYOD) environment: first, there is no all-in-one technology solution; and second, allowing personal devices onto the corporate network boils down to mitigating risk.

It’s not that there aren’t a plethora of BYOD technologies available. In fact, vendors push solutions that promise features ranging from mobile device management (MDM) to mobile network access control. But in most cases, these technologies address only portions of the overall picture.

Specifically when it comes to networking for a BYOD environment, there are a myriad of challenges that include perimeter security, bandwidth management and application optimization. A real BYOD networking solution could require an infrastructure redesign to enable application- and user-aware access control and bandwidth management.

For ArchitecturePLB, which has two offices and 60 employees, a complete network redesign is not an option. So Pickford has taken on one BYOD challenge at a time using a patchwork of strategies and tools that he admits leaves a number of holes.

Essentially this means that Pickford has to weigh the benefits of personal devices on the network against the risks. In this interview with, Pickford explains how he has handled it so far.

Q. Tell me about your network and what kinds of devices you are managing.

We’ve always been on a Mac platform, but we’ve also had to expand to incorporate more enterprise-level service, so there’s been an adoption of a Windows-based platform as well. We also recently started using Citrix to deliver enterprise-level apps to the Mac desktop.

[In terms of devices], we don’t follow the typical corporate restraints where equipment is issued and you have to follow strict policy. We try not to get in the way of our 60-member staff. What happens [instead] is that equipment is issued [or brought in], and after it’s out and in the field, we go backward and manage the security policy implications. It’s always quite a reactive scenario. That may be because of the way the network has evolved over the years. It’s also because our director will say, “We have a project coming up and we have to deliver X or Y.” Then we have to deliver the IT immediately. It’s not like we have a lead of six months to adapt. I think this is the case for most companies.

Q. How do you determine policy for which mobile users get access to which applications? What tools do you use to control this?

Some IT professionals that work in large companies with lots of IT infrastructure have policy controls through Active Directory, and they can have granular control over which applications [users can] see and what their password strengths are. We use policy control, but it’s more basic; it’s based on group policy.

All the users and groups belong to a central directory service, so we can manage centrally what they have access to, whether that’s SharePoint on a file server, for example. We are starting to move into application control, meaning I will give this user permission to use this application, but that’s quite new for ArchitecturePLB.

Q. How do you know what the device is accessing?

We use our firewalls to figure [out] who is connected to what, how much bandwidth they are using and what protocols they are using. We approach it behind the scenes, so it’s quite transparent to the users. They don’t see policy control limiting their access. The systems are gathering that information, and we can use that if we’re called to do so.

But at the moment, if someone downloaded the entire project database, we wouldn’t know. Our firewalls wouldn’t alert us based on a threshold control. Really our IT team wouldn’t have the resources to implement such a technology. It comes down to risk mitigation.

Q. What kind of firewalls are you using?

We put in these security appliances, and that’s what they’re called nowadays because they do more than one thing. They make our network more transparent and inform us what connections are being used from any device. They have intrusion prevention and detection, and they have filtering and controls. That was really important for us because in the past, we had a corporate network with servers, connections to the Internet, routers and firewalls that were pretty much unmanageable. We would open up a port to the Internet and the traffic would run across, but we had no way of knowing what was actually running across that connection. When we first installed these, we didn’t enable any controls, we just had them logging. Then we started looking at the logging because we have external support companies that log in, so we had ports open. We didn’t realize how many other people were also knocking on the door for our services.

Those servers were vulnerable because people—whether they were manual or bots—were knocking on the door of these servers, and that is essentially the beginning of denial of service. A port is tapped onto many times until the servers says, “I can’t cope with this anymore” and turns itself off. That is what we have had to manage with this new development of having more mobile device requirements for remote access.

Q. Once you let mobile devices onto the network, how much is bandwidth management a problem?

The problem with these devices is that the water becomes muddied because they are used for personal as well [as professional]. You find that people download music apps, maps, satellite navigation or games; the list is endless. And there is no way of distinguishing what’s theirs and what’s ours. You can see these devices come online [through the firewall], and then suddenly they spike as they try to sync their services. We don’t have a way to control that at the moment.

One solution, for example, would be to install in a completely separate line for these devices, and then you have to set up a trust policy in a sort of DMZ. You could try to control the devices at an application level, so if you have smart phone running corporate email and diary, you would allow those applications into the network, but anything else would go outside of the corporate network through a public Wi-Fi hotspot. But how do you do that practically? At the moment, I don’t think the technology is there to do it.

I think [eventually] we can try to control this through QoS management and bandwidth management. With the emergence of Web 2.0, you can no longer control web traffic or Port 80 or HTTPS, but we can use the Web now to bend applications within that port. Facebook is a classic example, where it’s Port 80. But then you find a game running inside that port. That is a security risk because it is running other protocols that are masked. What they’re doing with security firewalls is designing them to filter at an application level, so every time we build a new app or embedded program that works within HTML and Port 80, you can restrict those. I think that’s the data that I am starting to see on our firewall, so we can block or throttle specific applications.

We are more [concerned with] bandwidth than security. That comes back to the business in general. Do architects really need to worry about security as much as a government agency or any commerce company that keeps records on people? If I invested half my time into security, it would probably be misplaced.

Q. How important or useful are mobile device management (MDM) systems for ArchitecturePLB?

There are plenty of companies trying to sell us a unified solution for tracking mobile devices and having the ability to remote wipe. Most of the products we have currently, whether it’s the mail system or diary system, have slightly different solutions for dealing with remote devices to remote wipe or lock them. [MDM] keeps coming up on the agenda to look at, but we’ve not decided on one because it keeps changing. Every month another company comes out and says, “Oh we can manage it all from the cloud.” Then suddenly you’ll find Apple will bring out its own system. You’re kind of torn.

Q. Do you have one strategy at this point that you trust for securing data on remote devices?

If devices go missing, we have solutions in place to remote wipe the devices, and through directory services, we can immediately lock down users in the system so no further access can be gained. But in truth, there are definitely areas that can be improved. For example, our directors all run laptops, but we don’t encrypt all the data on those devices. The actual user accounts are locked, so you couldn’t log in, but if you were persistent and knew something about IT, you could probably get around those perimeter locks.

If we’re really talking about how we could secure our portable devices, we would talk about putting a mail server [for example] on a DMZ, and [devices] would be communicating with servers on a DMZ. We would have to redesign the whole network to accommodate that.

This is why Citrix has such a great sales proposition, because by definition the design of their product is secure from the ground up. You are not sharing data; you are sharing a screen interaction. This gets around the need to invest in redesign of the network to accommodate a more secure platform for remote devices.

Q. You mentioned the need for virtualized applications in order to solve software licensing problems related to BYOD. Can you explain?

I am finding software licensing significantly troublesome to manage within a BYOD concept. I read an article that demonstrated two possibilities for successful BYOD: virtualize applications or [offer] choice of hardware. ArchitecturePLB doesn’t offer a choice of hardware, thus when employees ask for applications to be installed on personal devices, or they ask for remote access from personal devices, we struggle to deliver the solution. In most cases, we have to offer “pool laptops” to cover demand simply because software licensing is not flexible. [Essentially] virtualizing applications to deliver the BYOD concept is the only way for ArchitecturePLB currently.

About the Author

Rivka Gewirtz Little is the executive editor of TechTarget's Networking Media Group.  She has been covering telecommunications and networking since deregulation of the FCC in 1996. She began her career as a daily news reporter in Texas and has been a frequent contributor to The Village Voice, The Houston Chronicle and numerous technology and business publications.

Article 5 of 6
This was last published in April 2012

Dig Deeper on Network virtualization technology

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Network Evolution

Access to all of our back issues View All