Implementing a Bring Your Own Device Policy (BYOD) in Your Organization

Bring your own device (BYOD) policies are more important than ever since smartphones became pervasive. I’d argue that even if you don’t want to allow personal user devices to access corporate data or applications, you still need BYOD policy best practices if only to acknowledge the fact that users are already bringing their personal devices into your organization.

Even if they aren’t accessing corporate apps, they’re connecting to your Wi-Fi networks and connecting to their favourite websites and apps from inside your network.

Let’s take a look at what a BYOD policy is, what questions to ask before you implement one at your organization, and what best practices should be followed to ensure it’s successful.

What is a bring your own device (BYOD) policy?

A bring your own device (BYOD) policy is a set of guidelines that allow employees to use their personal devices, such as smartphones, laptops, or tablets, for work purposes. The policy outlines how these devices can be used to access company networks, data, and applications while ensuring security, privacy, and compliance with the company’s IT standards.

What’s included in a BYOD policy

Key elements of a BYOD policy typically include:

1. Security Requirements: Defines the security measures employees must follow, such as using strong passwords, enabling device encryption, and keeping software up to date.
2. Acceptable Use: Specifies what employees can and cannot do with their devices while accessing company resources.
3. Data Protection: Outlines how company data should be handled and what to do if a device is lost or stolen.
4. Support and Maintenance: Clarifies the level of IT support the company will provide for personal devices.
5. Compliance: Ensures that employees adhere to legal and regulatory requirements while using their devices for work.

Questions to ask before implementing a BYOD policy

Before you can implement a bring your own device policy, you need to be clear on your goals. There are several questions that you need to ask, because the answers dictate how your policy will actually work.

1. What applications and data will be accessible?

Think BYOD security riskes: Will users be using the Wi-Fi to connect to the internet, or will they be accessing corporate data and applications? If you just want to provide internet access, the easiest way to handle it is to create a separate Wi-Fi SSID (perhaps even a “guest” Wi-Fi) and let employees use that for their personal devices.

Creating a guest Wi-Fi also allows you to implement appropriate firewalls and network-based scanning devices to help protect those devices. And remember, guest Wi-Fi should always be strictly firewalled away from any internal networks.

2. How sensitive are these applications and data?

If you do intend to allow personal devices to connect to corporate applications and data, you need to understand the risks. How sensitive is the data? In most cases, corporate data and applications range from mundane to mission critical.

You need to be careful with how you answer this question because users will want to access more applications over time. What’s a reasonable risk level on the first day of BYOD may not be when people want to work on the general ledger or access critical corporate intellectual property. Make sure you have a way to control the data and applications they can access. If you just blindly let them on your network, you don’t have this control.

3. Should corporate data reside on end user devices?

There are two ways to handle data on personal devices:

1. Allow the devices to hold potentially sensitive data
2. Allow users to display the sensitive data via a web browser or a specialized app, and then clear any locally cached content

The difference between these two options affects what happens if the device is lost or stolen. Do you need to remove the ability of that device to access the data, or do you need to somehow reach out to that device and delete the sensitive data?

Another question you may ask is, “How should the sensitive corporate data be compartmentalized on the device?” Should a user be able to cut and paste—or otherwise forward—the sensitive information from corporate applications using their personal applications? In many cases the answer to this will be “no.”

Both of these questions immediately dictate whether you will require a mobile device management (MDM) system and how it should be set up.

4. Where are the corporate data and applications housed?

At one time, all sensitive data was housed inside the corporate network. In 2020, it’s likely that at least some of the data will be located in some sort of cloud-based service.

The differences affect some important considerations. If users will access internal systems, then you need to think about whether they’ll access them only from inside the corporate network, or if you’ll allow remote access. If you want to allow remote access, then you need a VPN solution to go with your BYOD device policy implementation.

If the data is in a cloud-based service, then you need to think about how the cloud service will distinguish between a corporate device, a personal device being legitimately operated by an employee, and an attacker’s device attempting to access your data remotely.

Listen now: Abine CEO Rob Shavell explains how scammers can use completely legal and legit data to threaten your users and access your network.

As soon as you allow remote access, you need to include a robust authentication system in your plan.

Essential elements BYOD policy best practices

There are several essential pieces of technology to a successful BYOD implementation.

1. Wi-Fi and SSIDs

The first essential element is a Wi-Fi network. It’s easy to get bogged down at this point. How many SSIDs will you provision? Do you need to distinguish between BYOD devices and genuine external guests? Most of my clients have opted for a model that includes three SSIDs.

Read more: Wireless network architect Lee Badman explains the power of the SSID.

The first is an internal SSID that’s allowed to access internal systems the same as any wired device. Authentication for this SSID generally uses 802.1x certificates to allow for seamless authentication of corporate devices. In most cases, this network can access the public internet using the same internet firewalls and network-based security inspection devices as wired connections.

The second SSID is for guests, and it can only access the public internet. It’s firewalled away from the internal network. In some cases, you might want to allow guests to access certain internal systems such as video conference systems or servers in the DMZ. But I would only recommend providing such access if you’re able to put those accessible systems on their own separately firewalled networks.

The third SSID is for BYOD devices, and it has whatever access you plan to allow these devices to have. The way it’s authenticated depends on what your access requirements are. If you have an MDM system, then you should be able to push out a corporate certificate to be used for 802.1x authentication. In this case, it’s possible to roll the first and third SSIDs together.

If you have all of your corporate systems in internet-based cloud services, then you might consider rolling all three SSIDs together, since they have essentially the same security restrictions. However, I’d still deploy the guests on their own separate network for ease of management. You’ll want to be able to kick unwanted guests off the network periodically.

2. Two-factor authentication

As soon as you open your corporate applications and data to access from devices that you don’t control, or from networks that you don’t control, your needs for a robust authentication system grow.

If you plan to allow access to anything sensitive from outside of your network, I strongly recommend implementing some sort of two-factor authentication. This includes VPN access to your internal networks as well as access to any cloud-based services.

As an aside, if you have any corporate data in a cloud-based service, including things as simple as email services, I strongly recommend two-factor authentication. Passwords can be stolen or guessed far too easily—even complex passwords are frequently stolen because users like to re-use their passwords between accounts. You have no way of knowing whether somebody is using the same password on their work email and their Facebook account, because it happens to be one they like and have already committed to memory. Then if it’s stolen on Facebook, it’s stolen for work as well.

There are many excellent two-factor authentication solutions on the market. Some use a smartphone app that requires the user to click “OK” to gain access. Some use a challenge-response code with either a physical token or a smartphone app. Others send a text message to your phone with a code that needs to be entered. (The text message method isn’t considered highly secure because these messages can be intercepted, but it’s certainly better than nothing). And still others have a physical token that must be plugged into a computer.

Note that all of these methods can be defeated by using social engineering to trick the legitimate user into authenticating an attacker’s session—so they aren’t a panacea. But they’re vastly better than passwords alone.

3. Mobile device management

Finally, there’s mobile device management. Frankly, I don’t think I would ever recommend deploying a BYOD strategy without an MDM solution. Without it, you have no control over lost and stolen devices, you can’t push out certificates, you can’t push out application updates or security patches, and you can’t remove content if an employee leaves the company.

Most modern MDM systems will allow you to partition the device to prevent data leakage between personal and corporate applications and encrypt either the whole device or just the corporate data. And most of them are available for a wide range of mobile devices. Another key MDM feature would allow you to remotely remove content or “brick” the device if it’s lost or stolen.

But the challenge here is there are a lot of MDM systems out there and the features they offer vary greatly. It’s good to have a clear idea of your requirements, do research on the options, and then get one or more of the options into your lab to test. Some of them look good on paper, but are difficult to work with in practice. Others, depending on your requirements, could lack key features.

Other BYOD considerations to think about

There are also other functions that you might want to bundle in with your BYOD implementation. For example, if you have a DLP (data loss prevention) strategy, then it should also cover these devices, since they’re excellent vectors for insider data theft.

You should also consider some sort of endpoint security implementation on the BYOD devices. Endpoint security helps to ensure that malware doesn’t enter your network, as well as making it harder for an attacker to use these devices as an entry point into your infrastructure.

You should definitely consider how much access to the user devices your administrators have. Sometimes people have pictures and other highly personal information on their devices that administrators shouldn’t be allowed to access.

And, finally, it’s important to consider the implications of whatever remote “wiping” functions are available in your preferred MDM solution. Some of these solutions will only wipe out the corporate contents. Others will wipe the entire device, including user data. And some will allow you to select which option you want. Make sure you understand what you’ll be implementing, and make sure your employees understand as well. This is particularly important if they need to reinstall their devices should they leave the company.

---

One parting piece of advice is you shouldn’t compromise on the things that are essential to meeting your BYOD policy’s requirements. If you can’t get the budget for an MDM, for example, you’ll need to severely scale back the requirements to what can be safely delivered this way. Trying to do too much without the right tools is always a recipe for disaster.