Device security guidance

You may consider allowing personal devices to access corporate data through the web browser. This is the simplest type of BYOD, where users authenticate to SaaS (Software as a Service) application(s) via their web browser. During the session, some data will be cached on the user’s device. Typically, this approach is used to enable employees to access work email. The popularity of this approach stems from its simplicity and versatility, regardless of platform.

Simplicity can be attractive, but this approach gives rise to a wide range of risks. There are no technical controls that you can reliably enforce to prevent data loss, or access from insecure services. Additionally, you cannot get any confidence in the security or configuration of the devices used.

A compromised device could give an attacker relatively easy access to data as it is rendered in the browser, along with the contents of the browser cache, credentials, and security tokens of accessed services.

If choosing this type of access for BYOD, you should focus on ensuring your employees understand the risks, and particularly why the risks exist. Simply focusing on what needs to be done without the why, could lead to users de-valuing the risks.

Key Points:

Summary

Simple access to corporate data through a web browser

This approach reduces the attack surface accessible from the internet compared to access via a standard web browser.
 

Users are provided an interactive view of a corporate desktop style environment, with a suite of applications defined and managed by the organisation.

There are a variety of products that enable users to connect to a remote view of a desktop, or applications running on a remote server. This remote view means that minimal amounts of corporate data are cached on the user device.

Despite this, ensuring that the remote endpoint is communicating only with what it ought to, is essential, and can be technically challenging. Incorrectly configured remote access solutions (particularly RDP) are a common initial access vector in ransomware attacks.

This approach is still at risk if malware is present on the user’s device. However, these ‘thin client’ services are less risky than ‘thick client’ services, as they:

• Provide limited access to corporate data

•  Malware may still be able to: screen scrape (capture what is displayed to the user); key log (capture the input of pressed keys) to access data; or inject keystrokes/mouse movements affecting the remote machine.

•  Screen scraping captures only what is displayed to the user.

•  If users are only able to access non-sensitive information, this may be an acceptable risk for your organisation.

•  Key logging captures the inputs from keys pressed, which may include log-in credentials.

•  Whilst key logs can capture log-in credentials, using multiple factors of authentication will bolster the security of authentication requests.

•  Injecting keystrokes/mouse movements could lead to execution of software on the remote machine, such as running a command-line shell. A compromised remote machine working in conjunction with an already compromised client device could lead to exfiltration of data from the remote machine.

• Lower the risk of bulk enterprise data being exfiltrated as the files themselves are not directly exposed to a user’s device. As mentioned above, if malware can inject keystrokes/mouse movement, a remote machine could become compromised, allowing an attacker to exfiltrate data.
• Require minimal amounts of data to be stored on the end user device, so loss or theft of devices is less problematic.

•  If the user’s device is lost or stolen, minimal amounts of corporate data are stored on the device itself and therefore cannot be accessed without valid authentication to the device and to the VDI. If reported stolen, you will be able to remove VDI access from the device, and as such the only compromised data will be the small fragments on the device.

Some remote access solutions can allow you to gain assurances from the device before allowing access, including the detection of anti-virus software.

Strong authentication methods can also be enforced before granting access. However, whilst this provides assurance of identity, this alone does not take into account whether a device has been compromised.

As VDI solutions provide a remote ‘view’ of a corporate device, your security controls can focus on corporately managed assets, where you can enforce all necessary controls. Controls can be configured to minimise the copying or rendering of data outside of the virtual environment.

Key Points:

Summary

Users are provided an interactive view of a corporate desktop environment with a suite of applications defined and managed by the organisation.

One approach for reducing risk is to boot the user’s device into a managed operating system environment using bootable media, typically USB.

There are a variety of third-party products that can do this, as well as Windows to Go, which is built into some older versions of Windows. However, this approach may not be suitable for everyone due to the complexity of setup and the likeliness that device support will be needed. For example, the user may need to reconfigure the device’s firmware to enable booting from removable media.

Whilst this approach is arguably the lowest risk way of enabling home PCs to be used, you still cannot gain confidence in the underlying hardware. Firmware attacks on the host device are still possible, along with other risks, such as not being able to follow best practice on storing keys.

Key Points:

Summary

Bootable managed corporate environment

Using the Mobile Device Management approach to BYOD entails personally owned devices being enrolled in a corporate solution that grants the enterprise a degree of control over the device and its settings. This model is often referred to as ‘partly managed.’

All modern device platforms including iOS, macOS, Android, ChromeOS and Windows 10 support Mobile Device Management, each offering differing levels of security controls.

Mobile Device Management (MDM) software works in conjunction with the specific device when enforcing its security controls, so management capabilities will vary depending upon the device and platform. MDM software can often be part of an Enterprise Mobility Management (EMM) suite of tools.

MDMs are usually able to enforce some device-wide configuration policies, as well as policies which protect corporate data within apps, or managed accounts. Mobile Application Management (MAM) works in a similar manner.

This approach can give greater assurance of device security, but the level of control over a device can be concerning to the owner, making this a less popular solution.

Platform documentation

The corresponding features for MDM with BYOD mobile devices are:

• Apple iOS Device Management (without Supervision) (PDF), or User Enrolment (iOS 13+ only)
• Android Enterprise - Work profile

Some of the stronger security policies typically available in MDM solutions will not be available for BYOD deployments, so you may be unable to mitigate certain risks that you care about. For example, you will not be able to prevent users from installing new configuration profiles on iOS in Device Management (without Supervision) or any of these modes, which can change security settings of the device.

MDM monitoring capabilities

MDM’s can often report a wide range of device states, which you can use to establish the health of the device. However, the information presented to the organisation originates from the MDM and not the actual events generated by the device. A compromised personal device may also obscure or conceal its activity from MDM reporting.

Data which MDMs can report include:

• A list of apps installed on the device
• Whether anti-malware features are enabled
• Whether apps can be installed from less trusted sources
• Device unlock settings
• Whether device encryption is enabled

Some may even include information such as:

• MAC address
• Phone number
• Current and previous device names

MDM Security controls

MDMs implement and enforce controls at platform level (usually in kernel-mode) - a portion of the operating system. A device compromised at a more fundamental level can undermine these security controls.

Malware running with privilege (either through escalation on an unpatched device or through a user running as a privileged user) on a compromised device may be able to access cached data and the security tokens of services being accessed.

Choosing an MDM

Our MDM guidance and vendor documentation should be consulted before choosing your MDM solution, and you should have a full understanding of:

What devices your organisation will be supporting for BYOD?

What other types of flexible working the MDM may be facilitating, along with BYOD?

Key Points:

Summary

User grants the enterprise a degree of control and management over the device and its settings.

With Mobile Application Management (MAM), the user manages all aspects of the device, except for work applications, which are held in a container on the device and managed by the organisation.

It is common to use multiple container applications for different tasks. When provided by the same vendor, these behave as if they are one container.

MAM Controls

The organisation will have ownership of the data and resources within the containers. Corporate administrators can push settings to MAM-enabled apps which a user has installed within the container.

Security controls are implemented by the app and in doing so are not enforced by the underlying platform. Poorly configured devices or a compromised one could undermine such security controls.

Although a container approach generally provides less control of whole device settings, MAMs tend to offer stronger controls to protect and isolate corporate data from the user’s personal applications. For example, many container applications can prohibit copy and paste actions, or screenshots across the container boundary.

Some MAMs also allow device monitoring, including checking operating system versions. However, without corporate management of the underlying platform, this information is less trusted.

MAM suppliers

A variety of third-party vendors (typically MDM vendors) provide these container applications, and they can often be part of an Enterprise Mobility Management (EMM) suite of tools. Note, MAMs can be used with fully managed or corporately owned devices and so ensure that the controls you implement with MAMs are appropriate to BYOD.

MAM Apps

MAM-WE (Mobile Application Management without Enrolment) apps are usually downloaded by the users, rather than through a corporate store. If a malicious version is installed, it may not be possible for MAM-WE to determine if the application is malicious.

Malware infected devices may be able to gain access to corporate data and the security tokens for services accessed on the device. User information held in a separate profile outside the container, but using the same application may also be vulnerable (for example one mail application holding both corporate and personal profiles).

Key Points:

Summary

User manages all aspects of the device except for work applications which are held in a container on the device and managed by the organisation.