You should read and understand all the points raised by this section before proceeding with a new deployment of EUDs within your organisation’s network.
Wi-Fi
In general, devices which support Wi-Fi can be used securely on any Wi-Fi network which allows VPN traffic to transit the network. However, there are risks associated with using Wi-Fi which must be considered and accepted before its use is permitted.
Many devices expose a rich set of services when connected over Wi-Fi. Risk owners of deployments which use Wi-Fi should be content that the increased attack surface of these devices is within the bounds of acceptability. For example, some devices may expose synchronisation services over Wi-Fi to allow media and data to be synchronised.
Others may present a screen sharing service which allows the contents of the device’s screen to be shared with networked peripherals. Services may also be accessible locally when the VPN is connected, effectively causing a split tunnel. These attack surfaces should be considered on a device-by-device basis and only permitted where the risk is acceptable.
Many public hotspots redirect web traffic to a ‘captive portal’ page at first connection. User interaction (agreeing to terms and conditions, or entering a passcode) is required before an internet connection is allowed. Captive portals require devices to browse to a website outside of the VPN connection. During this time, devices can be targeted for attack by the network itself, or by hostile users on that network.
Configuring current devices to enable this type of connection requires a mechanism to allow the user to disable or circumvent the VPN, increasing the risk to data in transit. Allowing captive portal interactions is not recommended where users are not trusted to manage their own connections appropriately.
Captive Portals
Devices that have an always-on VPN will not be able to connect to Wi-Fi hotspots that use captive portals unless the always-on VPN is disabled. Connecting to a Wi-Fi hotspot with a captive portal will need to use an untrusted connection that is not protected by the VPN. There are several risks to EUDs that organisations need to be aware of if they enable the use of captive portals on their devices:
Risks from using captive portals
Unencrypted data can be read by the Wi-Fi hotspot
The Wi-Fi hotspot will be able to read any data that is not encrypted in transit. The wireless connection used by most public Wi-Fi hotspots is also not encrypted, meaning that anybody nearby will be able to read data being sent between the device and the hotspot. This could include sensitive information such as passwords, cookies and personally identifiable data.
Data held in a browser could be stolen by a malicious hotspot
Web browsers are commonly used to access trusted services. Consequently, they are often configured to automatically authenticate against web applications in order to provide a seamless user experience. In order to do this they will save credentials and website content for future use.
An untrusted Wi-Fi hotspot can alter or re-route traffic as it is sent to the web browser. This can allow the hotspot to access data stored by the browser such as authentication cookies, browsing history and data temporarily cached by the browser.
Your organisation’s Internet gateway will be bypassed
Some organisations use security functions on their external gateway to supplement the controls on their end user device. This might include:
- logging all web access to audit compliance with corporate policy, and provide more situational awareness when an attack is detected elsewhere on the network
- anti-malware scans on files and web pages before they are loaded on the end user device
- reputational filtering to block potentially malicious sites based on data from cloud anti-malware services
- filtering out categories of sites deemed inappropriate for the workplace
- applying data loss protection rules to attempt to block sensitive data being accidentally sent to the Internet
- preventing the user from installing an untrusted root Certificate Authority’s certificate
These capabilities will not be available while the VPN is disabled in order to allow access to the captive portal. This can result in unmonitored and less protected Internet access until the user manually establishes the VPN connection.
Mitigating the risks from captive portals
You can adopt a variety of approaches to mitigate the risks from captive portals, some providing more confidence than others.
Some approaches attempt to make accessing the captive portal safer, before falling back to using a VPN to protect data in transit once connected to the Internet. Others provide alternative ways of connecting to public Wi-Fi networks.
The residual risk of each approach will vary depending on the platform being used and the exact solution chosen. You should choose a solution that balances usability, cost and platform features with residual risk. Where these risks are unacceptable to the users and the organisation, you should consider providing an alternative means of data connection, such as a mobile connection.
Alternative ways of authenticating to Wi-Fi
Some technologies allow devices to authenticate to a Wi-Fi hotspot without using a web browser. These include:
- Wi-Fi CERTIFIED Passpoint (previously known as Hotspot 2.0) and WISPr which authenticate to the hotspot using a simple protocol and don’t require the use of a web browser.
- per-user WPA2 passwords which authenticate to the hotspot at the same time as the device connects to the Wi-Fi, allowing the VPN to automatically connect as soon as the device connects to the Wi-Fi hotspot.
- Wi-Fi network branded apps that automatically authenticate to a network of Wi-Fi hotspots. The exact functionality varies per app, though they usually run in a sandbox and use a separate web browser to let the user log in.
- agreements with Wi-Fi networks for specified devices to bypass the captive portal, and therefore allow the VPN to connect automatically when the device connects to the Wi-Fi hotspot.
Device patching and configuration
Well maintained and configured devices, following the concepts outlined in this guidance, are an essential part of any effective mitigation strategy.
A device that has security patches applied promptly to both platform and all installed applications will be more resistant to malware and so less susceptible to attack.
This approach is most effective when combined with other mitigations, such as procedural controls to protect any corporate data stored on the device. Appropriate procedural controls include:
- minimising the time between connecting to the public WiFi and connecting the VPN
- not accessing sensitive data on the device until after the VPN has connected
Particular attention should be paid to:
- patching all software installed on the device including the platform itself
- enabling sandboxing mechanisms to separate the captive portal from sensitive data
- effective use of application whitelisting to reduce the risk of drive-by downloads
- making use of on-device reputational site filtering and malware detection
- ensuring that security configuration cannot be altered by the captive portal or the user
- using modern encryption standards including certificate pinning on services that send sensitive data over the network
- ensuring that the VPN automatically establishes a connection once the Internet is accessible
On-device sandboxing
Most of the risks listed above can be mitigated by providing separation between the captive portal and the rest of the platform. This can be achieved with a sandboxed app, virtualisation tools or even just a modern web browser configured to use a non-persistent profile.
Solutions should prioritise providing smooth and intuitive user experience between connecting to the Wi-Fi network and the device establishing the VPN connection. This approach can remove the reliance on procedural controls.
Preferred solutions should:
- protect the platform from any malicious content on the captive portal. Separation is usually best achieved when using the sandboxing that is built into the platform’s app framework (designed to protect apps from each other and protect the platform itself) or using hardware-backed virtualisation.
- prevent the captive portal from accessing data on the device. Sensitive data can include credentials, user’s files and data in other apps. As different users may treat different data as sensitive, this mitigation is most effective when the captive portal cannot access any data stored on the device.
- prevent the captive portal from accessing data stored in the browser which is used to access your organisation’s data. Sensitive data in the browser can include cookies, saved passwords and data intentionally cached by web apps.
- be non-persistent. Configuration or cached data should be cleared each time a captive portal is accessed to minimise the impact of connecting to a malicious hotspot.
- ensure that the captive portal cannot reconfigure the device. This includes installing new trusted certificates into the browser or platform.
- use technical controls rather than procedural controls to enforce separation between the captive portal and the browser used to access your organisation’s web applications.
Device management
Device management products are used to remotely administer, configure and audit end user devices. In the context of EUDs, these services are generally referred to as Mobile Device Management (MDM) or Enterprise Mobility Management (EMM) products.
When deciding which MDM to use with your deployment, there are several key considerations.
Product features and policies supported
Ensure that the selected MDM product can enforce the security policies that are recommended in the per-product security guidance. The range of capabilities varies between devices, so check that the MDM product can support all the platforms used by your organisation.
Product security
MDM products are attractive targets for attackers. If they are able to compromise the MDM server an attacker will be able to perform remote administration and password resets on all enrolled devices. Compounding this, MDM servers are often placed in internet-accessible locations within the corporate network, directly exposing them to external attackers. Consequently, the reliability, robustness and security practices of the MDM product are extremely important.
When choosing an MDM product, consider its development lifecycle and your resultant confidence in the security of the product. Is there a good track record of fixing security issues? Are security incident management procedures in place to handle future problems? MDM products can be independently evaluated and certified to Foundation Grade, and details of such products can be found in the CPA certified products list.
On-premise or cloud deployment
Many MDM product vendors offer hosted versions of their product. Using cloud-based MDM products may decrease costs, but can increase risk. For example, other users of cloud services may be able to more easily attack or degrade the management service for your devices. If you’re considering using cloud-based MDM services, read the Cloud Security Guidance for information on managing the risks associated with using public cloud services.
Bring Your Own Device (BYOD)
Whilst ownership of a device makes many information security aspects much simpler, it is not a prerequisite of this guidance. What is necessary is that the device is placed under the management authority of the organisation for the complete duration it is permitted to access the organisation’s information.
To ensure information security when using devices not owned by the organisation, they should take control of device management at the point of provisioning, ensuring that the device is placed into a ‘known good’ state prior to allowing it to access information. Limitations of current technology mean that a ‘health check’ or ‘device status’ check is not sufficient to verify ‘known good’ – malware can easily subvert such a check. If possible, consider returning to an understood state such as by a firmware reinstall or wipe to factory state and replacing any existing configuration on it.
Device interfaces
Some devices allow administrators to exert control over their external interfaces – such as Bluetooth and NFC – which either prevents them from functioning, or restricts their functionality to a subset (such as restricting what the interface can be used to connect to).
Using these controls can help to reduce the overall attack surface of a device, and prevent information disclosure from the device (such as by removing the ability of the user to share information directly). However, the impact on the usability of the device can be significant, so administrators are urged to carefully consider the necessity of applying such controls.
We strongly recommended that the use of these interfaces should be limited to non-sensitive information, and that information which an organisation wishes to protect should not be transmitted over these protocols. For example the use of Bluetooth headsets for non-sensitive voice communications presents a lower risk to data than the use of Bluetooth keyboards connected to the device would. In the latter case, sensitive typed data is transmitted over an unassured protocol.
Browsers
Many organisations deploying this guidance will want to access internal and external web services using a web browser. There are many web browsers available for most platforms, so it’s important to consider the risks associated with each type of browser, and to balance that against the useful functionality provided by the browser.
Modern browsers are feature-rich interfaces which enable users to be highly productive with their time online, but these features often have an impact to the security of the device and its data when used. For example:
- Browsers may cache credentials by offering a save password facility. You should ensure that your organisation is content with how this information is protected on the device, or disable any information caching functionality.
- Browsers may permit the concurrent browsing of Internet and intranet web pages in separate tabs. This may mean that the browser process is handling untrusted code and sensitive data at the same time, with the browser required to enforce separation between the two domains. This presents a large and rich attack surface to the tab running untrusted code and the browser must therefore be robust to attacks from that code.
- Browsers may allow plugins to be installed. Typically these plugins run with the same permissions as the browser itself, so plugins must be fully audited and trusted before their use is permitted.
- Browser vendors regularly release updates to add features and fix security issues. As the attack surface of browsers is very large, and the chances of encountering malicious code is high, these security updates must be installed regularly and quickly following their release.
Ultimately, devices used for web browsing should use a modern, regularly-updated, and well-supported product which takes advantage of the native security features of the underlying platform.
Anti-virus and anti-malware protection
The EUD Security Principles note the importance of reducing the risk from malicious software and content based attacks. On a number of platforms this is achieved by using anti-virus or anti-malware software which will usually be purchased from a third-party, but several platforms will meet this requirement through other mechanisms.
When deciding if a third-party anti-malware product is necessary, you should assess the risk of malicious code being able to get onto the device and run. The extent to which application whitelisting is available and configured on the platform will be a significant factor, as will the ability to ensure incoming content is always routed through enterprise defences. The use of software restriction policies (or other security controls) native to the platform will also be a factor in deciding whether anti-malware or anti-virus products are necessary.
If you decide a third-party product is necessary, we recommend you:
- consider the management tools available. Specifically consider whether configuration policies can be centrally managed, and whether software and signature updates can be automatically rolled out across the device estate
- consider the audit tools available to the enterprise. Events from the product should be captured into a central location where they can be prioritised and investigated as part of an incident response plan
- consider whether the product provides heuristic and/or signature-based scanning
- consider the usability impact of the product on the platform (battery life, performance, etc), and do not layer multiple anti-malware products on top of each other – there is little evidence to suggest this lowers the risk of malware infections, but this can impact hugely on performance of the device.
Many products now expect to be able to communicate with online services provided by the vendor in order to gain access to better analysis capabilities. You will need to consider whether these communications are able to transit via the enterprise and whether sensitive data could leak through these channels.
Security updates
Manufacturers will regularly release security updates and patches for their products. These updates should be applied regularly to ensure that devices are not compromised by known security issues.
For larger patches or feature releases, the security impact of any new features not yet described in this guidance should be considered before their use.
Source: NCSC
