SISE (300-715) | Bring Your Own Device (Part 1) / by MBNE

What is Bring Your Own Device?

Historically, corporate network access was provided and controlled by the organisation itself - corporate desktop PCs, laptops and other devices would be manually provisioned for network access. Requirements for modern networks are ever changing - now users and resources are moving away from the traditional corporate offices and data centres, into remote workspaces, the home and the cloud. Now, there is a need to support many types of users and endpoints with different security requirements. In other words, the network perimeter has moved significantly and the number of use cases that require support have greatly increased.

Examples of this include IoT and personal devices, remote workers and contractors who require differentiated access permissions. Additionally, the trend of business resources and services moving to cloud computing platforms like Amazon Web Services, Google Cloud Platform and Microsoft Azure is a particular challenge. Throw an uncontrolled personal device into the mix and a whole host of potential security issues become apparent.

What does that mean for security-focused engineers? Well, as the network perimeter changes, so does the risk to security and associated complexities of visibility and enforcement. This brings a host of challenges for network engineers. For example, managing the security posture of a personal device can be difficult, because your organisation doesn't directly own or manage that personal device.

On modern networks with modern requirements, a secure Bring Your Own Device (BYOD) model is becoming more important. This means that the same organisational security policies should be adhered to, on devices that the organisation does not directly own or control. Considerations such as user and device identification, device type, access type and location are all important context about the BYOD device trying to access the network.

Challenges with BYOD

User credentials typically involve a single authentication - if using a personal device, the authentication itself could succeed, but other factors such as the type of device, time of day, location, and security posture of that device cannot be managed effectively. This poses a risk to organisations who require an increased level of control of the permissions granted to different groups of endpoints. Therefore, providing a secure BYOD model requires the use of mechanisms to assess and manage access from non-corporate devices.

One method used to tackle this challenge is BYOD Onboarding, another is to use Mobile Device Manager (MDM) software to onboard the device.

Mobile Device Managers are able to perform functions such as remote wipe, screen lock, encryption, certificate provisioning and supplicant provisioning. However, MDMs solutions have a higher cost attached to them due to the per-device costs typically attached, when for onboarding only the certificate and supplicant provisioning is required. Onboarding is the process of registering a device with either a BYOD registration portal or a MDM portal for the purposes of enforcing limited security policies on that device.

With regards to ISE, the following describes the two methods of controlling BYOD devices:

  • BYOD onboarding - Register a new BYOD device with ISE, provisioning a certificate to the device, and configure the devices native supplicant to correctly connect to the network.
  • MDM onboarding - Register a new BYOD device with a Mobile Device Manager, install MDM client software, then enforce the configured security policy on the device.

In both cases, the goal is to make the onboarding solution self-service so that IT do not need to be engaged.

What is the use case for Bring Your Own Device?

A BYOD solution has to strike a balance between Security and Productivity. The BYOD solution should reduce risks as much as possible, whilst allowing enough visibility to be able to react to changes in the security posture of the BYOD device. However, the solution is still used by users, who required a simple user experience on their chosen device, and expect the same or similar level of access and flexibility as a corporate managed device.

As described previously, the most common use case for BYOD is (of course) to permit limited access to a given corporate network from non-corporate devices. This facilitates greater freedom and flexibility for end users, business benefits such as increased productivity, and can also result in lower overall costs through a reduced investment cycle in laptops, mobile devices and other types of endpoints that traditionally must be purchased and provisioned by the organisation before any projects could be completed.

Goals of BYOD

A BYOD solution would ideally try to implement some level of security enforcement before the device can join the corporate network and access resources. Some examples of security enforcement are as follows:

  • Network Segmentation - If the BYOD device could be segmented from other types of devices, that would aid in enforcing security measures. For example, a group could be created for Corporate Devices, a group for Guest Users and a group for BYOD Devices would allow for a differentiated security policy with appropriate authorisations.
  • Secure the Endpoint - If the endpoint could be secured in a manageable way before accessing the network, such as by authenticating, authorising and provisioning identity certificates, this would improve the security posture of the device. Other considerations include maintaining OS updates, anti-virus and anti-malware checks and the proactive blacklisting of unwanted applications are also important.
  • Onboard with a Portal - A portal-based onboarding solution would require the user to follow a process to successfully register the device on the network, allowing the network to understand and categorise the device and user before appropriate permissions are granted such as simple Internet Access or Limited Privileges.
  • Use an MDM solution - A Mobile Device Management solution could allow the organisation some additional control over the security status of the device, at the expense of user autonomy.

BYOD and End Users

A BYOD solution, especially where MDM is concerned, has some inherent issues:

  • User Privacy and Productivity Concerns - Users may be concerned about the privacy of their personal data if an MDM agent is installed on the device. They may also feel that they can work better with a familiar personal device rather than a corporate provided device.
  • Organisational Security Concerns - Conversely, the organisation has its own concerns about allowing personal devices to have access to company resources, and the potential of valuable data (email, VPN connectivity, application data) residing on a device that doesn't belong to the company.

Therefore, the End Users need to understand that there is a trade-off between the convenience of using a personal device, versus the security risk that is associated with using those personal devices in a corporate

To educate the users, and to manage the Productivity vs. Security concerns, alternatives can be offered, to strike an agreeable balance:

  • A Guest Portal - Used to provision specific services only - this provides the segmentation and some security controls, but is less convenient for the end user.
  • A Secondary Device - Could be issued to the user, but with less convenience and additional cost to the company.
  • Explain the Risks - User education goes some way to help users understand the need for security measures for BYOD, such as patching and device maintenance, external security threats, increased costs for infrastructure and support as well as the increased risk of data loss that the business needs to mitigate somehow.

Now that we have an overview of BYOD and some of the thinking behind why you might want to consider it for your organisation, let's take a look at what the solution actually looks like.

What protocols and components are involved in Bring Your Own Device?

Before talking about the specific protocols and components used with a Cisco ISE-based BYOD solution, we need to first understand the different types of onboarding that are supported by the solution.

Onboarding of BYOD devices can be considered as one of two types, as required by the organisation:

  • Device Registration Only - The device is registered to ISE via the built-in My Devices Portal which can be configured to allow for a limited authorisation - e.g. Internet Access only.
  • Device Onboarding and Provisioning - The device completes the full onboarding process, including supplicant provisioning and (optional) EAP-TLS certificate provisioning.

Device Registration Only - via My Devices Portal

A dedicated My Devices Portal is typically used to provide limited network access. It can also be used as a self-service portal to reduce the support needs of the organisation. The purpose of the My Devices Portal is to allow for self-registration, meaning that the management of personal devices is administered by the end user through a dedicated portal.

The ISE network admin can configure the portal to suit the organisational requirements, and enforce the appropriate access for those endpoints. Other options include enforcing a device limit, Acceptable Use Policy, password change controls and configuring self-service device management (such as add, remove, change, report lost and stolen, etc).

This use case would support a simple Guest Access solution, with personal devices which are subject to network access control via ISE as opposed to a basic Guest Wi-Fi SSID.

Device Onboarding and Provisioning - Dual SSIDs vs. Single SSID method

The full onboarding and Provisioning process would be used to deliver the complete BYOD experience (MDM integrations are an optional component of this type).

Both BYOD Onboarding types have multiple methods to achieve the required registrations:

  • Dual SSID - With the Dual SSID onboarding method, the user does not need to configure the supplicant on the device as they connect to an Open SSID. The employee authenticates to a web portal for network access. The employee connects to the Open SSID for initial provisioning, and then connects to the Corporate SSID after the provisioning is completed (either automatically or manually).
  • Single SSID - With the Single SSIG onboarding method, the 802.1X supplicant must be manually configured to allow a connection to the Corporate SSID. The authentication used for the corporate SSID is used as SSO for the onboarding and provisioning process. A CoA is used to provide full-access after the provisioning process is completed, without requiring the user to log-off.
  • Wired - The onboarding process happens over a Wired port instead of over a Wireless LAN.

So far, so good. However, there are some prerequisites for BYOD with Cisco ISE, so let's take a look at these next.

What are the prerequisites for BYOD with Cisco ISE?

The Cisco ISE BYOD solution is an advanced ISE feature that builds upon foundational functionality such as implementing 802.1X, MAB, NAD configurations and Web Authentication features.

BYOD in particular relies on the following logical components to operate correctly:

  • URL Redirection
  • AAA Framework - including 802.1X, RADIUS, RADIUS CoA and MAB.

BYOD Prerequisite - URL Redirection

URL Redirection is used to intercept traffic coming from the endpoint on the NAD, and redirect it elsewhere. This is important if your use case is to redirect traffic to ISE before it goes elsewhere, like the internet. In most cases, it is HTTP and HTTPS traffic that is redirected. In fact, modern operating systems automatically check for a redirect when connectivity to a Wireless network, and may proactively send a HTTP request in order to initiate the redirect towards a Guest portal, or similar.

A typical Guest Flow that uses URL redirection may look as follows:

  • Step 1 - A guest user connects to an open SSID
  • Step 2 - The WLC (ISE NAD) takes the MAC address of the user and forwards it to ISE as a MAB authentication request.
  • Step 3 - ISE authorization policy determines this is device is a Guest and requires a URL redirect - a URL Redirect response is send to the NAD, with a unique session ID. This redirect is now enforced on this unique session and only the permitted traffic in the associated redirect ACL is permitted.
  • Step 4 - The user tries to browse to the internet, by typing a web address into the browser, such as www.google.com
  • Step 5 - The WLC intercepts the HTTP/HTTPS request from the client, and sends a redirect response to the client with the session-specific ISE URL.
  • Step 6 - The client browser receives the redirect and instead goes to an ISE portal, typically to prove guest credentials.

Redirect ACL

URL Redirection relies on a Redirect ACL in order to allow certain traffic from the client onto the network to allow the basic requests to function. These include traffic to ISE, DNS, DHCP at a minimum and any other guest specific flows required for the specific use case for the organisation. All other traffic should be blocked and redirected, especially HTTP and possibly HTTPS.

Some considerations regarding the Redirect ACL include:

  • The Redirect ACL needs to exist on all NADs that will be used to perform URL Redirection. It is referenced directly by ISE so the ACL name needs to be consistent.
  • The Redirect ACL determines what traffic the NAD gets redirected and which is allowed to pass.
  • Pay attention to the syntax on the NAD - Cisco switches often use deny statements for the traffic that should NOT be redirected, and permit for traffic that SHOULD be redirected. However, on WLCs, the reverse is true - deny statements will redirect, and permit will not.

Other important URL redirection components include:

  • HTTP/HTTPS Server - The NAD needs to have its HTTP and HTTPS server functions to be enabled, in order to be able to perform URL redirection.
  • Switch SVI / Routing - The NAD must use either an SVI on the endpoint VLAN, or the switch management VLAN must have a route to the endpoint VLAN. The switch will use the management VLAN IP by default to respond to the intercepted HTTP/HTTPS request.
  • IP Device Tracking - The switch needs to know the IP address of the endpoint to bind it to the URL Redirection - IPDT can provide this and is required for a number of ISE features to perform MAC-to-IP bindings.

URL Redirection Design Considerations

There are two components of URL Redirection that pose important design decisions that should be considered carefully for your deployment:

  • HTTPS redirection - Many websites use HTTPS by default, but redirecting HTTPS has a large hit on resource utilisation of a NAD, especially on a WLC. However, if you don't redirect HTTPS, a lot of users will never actually get redirected to the ISE portal in the first place. Additionally, you could get certificate warnings in the browser, because the HTTP request doesn't match the certificate presented by ISE redirect. You must therefore consider if you will need to redirect HTTPS at all, since most operating systems already detect redirects and automatically open a browser window and send a HTTP request to trigger it in the first place.
  • DNS - The URL sent from ISE will use the full FQDN of the PSN node that served the request. This infers that the endpoint needs to be able to resolve DNS as well, or even resolve web-based resources like the Google Play store in the case of Android devices. Therefore, DNS services must be available to the VLAN used by the endpoint.

BYOD Prerequisites - AAA Framework

BYOD solutions rely heavily on the AAA framework to function correctly, including:

  • RADIUS
  • 802.1X
  • MAB configuration - this is used for non-802.1X authenticating endpoints and Web Auth.
  • RADIUS Change of Authorization (CoA) - a key component of the Cisco ISE BYOD solution - it cannot work without it.

This section introduces the concept of BYOD, discusses the challenges and use cases for a BYOD solution and introduces some foundational prerequisites for the Cisco ISE-based BYOD solution to function successfully. Part 2 will look closely at the building blocks of the ISE BYOD solution, including provisioning policies, several portal configurations and policy sets required to tie the components together.