SBN

Addressing Bring Your Own Technology

How to implement a Bring Your Own Technology strategy is still one of the most rampant conversations we have everyday with businesses.  There is no single technology that is going to make the implementation successful.  The goal of this guide is to outline the variables that need to be addressed so that you can find an approach that will best fit your organization.

There are a few reasons organizations choose to have users bring their own technology.  The first step in figuring out what to do about BYO is to figure out why you are doing it.  What’s interesting is that as time goes I’m finding that people aren’t really sure if they are trying to enable BYO or prevent it.  Either way this guide will have you covered;

  • Employee satisfaction – Because of all the great smartphone and tablet options available, business users are leveraging their consumer smarts and wanting to bring them to the business meeting.  It is difficult to stop users from walking in with these devices so may as well prepare for it.  There is also a new generation of users who are used to using certain types of devices.
  • Cost savings – There can definitely be some cost savings to users bringing their own equipment to work rather than providing them.  You just need to plug in a few variables to figure out if this applies to you.  Here is a post on the topic.
  • Increased security – There may be an opportunity to keep data in your private datacenter under a program like this.  Either way, BYO needs to be addressed because people, users or not, can probably bring their own devices into your network today.  Just because you say no doesn’t mean they can’t.

BYOT involves technologies such as laptops, tablets, and phones today.  For this article all aforementioned devices types will be included when considering policies and associated controls.

Policy

Each of the policies developed should start with your Why statement.  It is important to articulate specifically how you want the program to look so that you know what changes will need to be made.
A BYOT Policy must be developed first to define what the program means to your organization.  Answer the following questions in the form of statements and you should be off to a good start.
  • What roles in the organization are allowed to participate?
  • Who pays for the hardware?
  • Who pays for the telco plan where applicable?
  • What type of management of the device will the organization implement?
  • Who and what is allowed to connect to the network?
From the organizations I’ve been working with most will allow the use of all employee owned smartphones and tablets.  The employee’s pay for their own devices and plans.  The company will often provide a monthly stipend for the telco plan on the phones and not allow the user to expense anything over above and beyond.  The devices will be managed by the organization in order to push a pin, email, calendar, contacts, and corporate wifi profiles.  Then be able to partially or fully wipe the device if the organization ever feels that the data is at risk.  
Some differences; In many financial institutions this is being permitted to small groups without access to sensitive data.  Some organizations only allow one type of device.  We have seen some organizations only allow Android where others only allow Apple.
A Network Access Control policy may already exist in the environment because the wired and wireless networks have been in place for so long.  It is important to clearly define how users are permitted to connect their own devices to the network.  And more importantly implement enforcement of this policy automatically rather than leaving it to the user.  Think about your environment today.  Is there anything in place to prevent a user or guest from plugging into an Ethernet port and getting the same access as a regular user?
  • What roles in the organization are allowed to connect their own devices to the network?
  • What networks are they permitted to leverage (wired and/or wifi)?
  • What network resources will they be able to connect to internally from their own device?
  • What type of devices will be allowed to connect?
  • What type of device management will the organization implement, if any?
This is an area where we definitely see a lot of inconsistency.  If you are going to allow users to connect their personal devices there are definitely ways to do it in a safer way.  One way would be to identify BYOT devices by device type, Operating System, and user.  When users in the BYOT program connect to either the wired or wifi networks you can place them in an IP subnet with a single IP address.  This would prevent them from communicating with any other IPs directly.  This is an important restriction because if you do not manage the device you have no way of cleaning compromised systems.  In a single IP subnet all traffic from the users device would have to come back to the firewall for interrogation.  From there we can permit them to use our DNS server, Outlook Web Access, and perhaps our Citrix or VDI.  This type of configuration can significantly reduce the potential of a users own device compromising other devices in your environment.  It also reduces some of the risk of data loss by keeping all of your data on your systems rather than allowing them to get it on to theirs and walk out of the facility with it.

Claroty

Infrastructure

Now that you have articulated how you want the program to be executed it’s time to look at some of the infrastructure to see if it can handle it.

Think about users downloading and updating their systems and apps.  They are going to prefer to do that in your high speed network than their residential Internet connection. 

Many organizations don’t have WiFi deployed yet.  Many others who do deployed it many years ago as a secondary luxury network.  One thing in common with many devices that users will bring it under this program like a smartphone, tablet, or even ultrabook will not even have an ethernet port.  A wireless site survey will help to determine if there are enough access points  to support the new devices.  Keep in mind that the WiFi infrastructure needs to connect to the core and disritution network so it’s important to determine the capacity of this environment too.
Estimate for every user to have 3 devices, a phone, tablet, and laptop.  Some users may have multiples of each still.  A great way to find out for sure is to send out a survey to all employees describing the program and ask them what they would likely do.  This will give you a good indication of the level of participation.  These modern devices are definitely noisy with their synchronizations and constant app updates.  The amount will clearly depend on the user however I would estimate at least 500MB per day per device.

A better approach is to monitor your WiFi connections to your core/distribution network for regular usage of in your environment.  If you know approximately how many of these devices are currently leveraging your network and how many you anticipate would participate in a program you will be able estimate more accurately the new load on the environment.  One of my favorite tools for network monitoring is http://cactiez.cactiusers.org/.

Access Control

Access Control is the area where we take the Network Access Control policy and make it a reality in the network.  
Network Access Control is a technology that may already be in your network today.  It can’t often be found in WiFi access points, Network Intrusion Prevention Systems, or as a dedicated server appliance.  My recommendation is to always investigate what you already have.  Every new technology is just another thing that needs to be maintained.  And every new cost added to the BYOT program reduces the Total Cost of Ownership.
The challenge is, to do it right you need to enforce NAC on the wired network too.  Therefore a separate NAC appliance is typically going to be the most robust way to enforce the policy throughout the environment.
The first step is to define your VLANs.  There is probably already one in the environment for general use.  PC’s can talk to each other, they can get to internal servers, they hopefully have restricted access to the DMZ, and they can get to the Internet.  This would be considered a privileged network.  A new VLAN needs to be created for BYOT with the restrictions discussed earlier.  It may be a network that only has access to the Internet, DNS, and VDI.
Typically the way NAC works is through a protocol called 802.1x.  When a user connects to the WiFi or wired network the WiFi access point or switch is going to look for 802.1x protocol coming from the client.  If the client device does not have this enabled you would automatically place them in the BYOT network defined above.  So everyone will be placed into this restricted network as a first step.  On your corporate deployed PC’s you will need to enable 802.1x.  When those users authenticate their VLAN will be set to the privileged VLAN.
The most confusing thing about NAC is that you are really restricting access to all users as they connect, where today they probably connect freely.  When you find out that they are authenticated or are on one of your corporate deployed devices you would elevate their privileges.  This concept can be tricky so it is recommended to keep the NAC policies simple to start.  The moment someone is put into the restricted VLAN when they should be in privileged their could be serious backlash.  Clearly, NAC is a necessary component though if you want to permit unmanaged (and probably unsecured) devices to use the corporate network.  This is also a technology that many organizations use with or without BYOT.  It’s a great way to enable users to bring their own technology, but if you don’t want anyone to bring their own technology this is the only way to stop them.

There is more information in this post.

Device & Application Management

Finally we get to the devices themselves and as close to the data as possible.
As described earlier Mobile Device Management today is exactly that, device management.  In most environments policies will be created to push and enforce a pin, email, calendar, contacts, and a WiFi profile.  This is a great way to know that any device that is connecting to the environment has some basic security on it and that you can at least wipe it if necessary.  It also helps to secure the WiFi because you don’t ever have to give a key to users, and could even push certificates for an extra layer of authentication.  With the number of devices it is not worth the time of the help desk team to be walking users through configuring these settings.  Some newer functionality includes the ability to block or encrypt apps.  If you wanted to block a cloud storage app on mobile devices because you don’t want users storing your data outside of your environment, you can now do that.  If you want to take it a step further and enable them to use someone elses storage network but keep the data safer you can now encrypt and even wipe that data.
One of the best ways to enable users and keep data safe is with application or desktop virtualization.  In this model the user sees the application or an entire desktop on their device that is being published from the datacenter.  The best part about it is that if configured correctly all of the data stays in the datacenter.  It doesn’t matter what type of device the user is using because the data doesn’t actually get saved onto their client device.  Some of the downsides may be screen real estate and usability, along with the fact that the user must be online in order to get at their data.
URL or traditional content filtering can also help keep data safe.  If users can’t get to file sharing websites like Dropbox or Box the data can never get there.  Now you only have to worry about YOUR network getting hacked and not theirs too.  One of the challenges here is that it can be tricky (not impossible) to keep these policies enforced when the user brings their device home.
Data Loss Prevention is also recommended particularly at the email gateway.  DLP can look at specific content and make decisions on how it can be used.  If you do not want client contact information, or your employee Social Security/Insurance Numbers, or credit card numbers to get onto any type of mobile device in this setting, one way would be to prevent users from sending it via email.  This is probably best practice anyway.
Bring Your Own Technology can be a great way to increase employee satisfaction, reduce the costs of client devices, and reduce help desk costs.  There are many permutations on how to implement a program like this.  It is important to look at your program holistically to make sure everyone is comfortable with the results.
As always I’m more than happy to discuss any of the strategies presented here specific to your environment.

*** This is a Security Bloggers Network syndicated blog from Insecurity authored by asdfasdfasdfasdf. Read the original post at: http://stephenperciballi.blogspot.com/2013/04/addressing-bring-your-own-technology.html

Application Security Check Up