Guidance

EUD Security Guidance: Samsung devices with Knox Workspace

Created:  15 Feb 2018
Updated:  15 Feb 2018
Secure configuration for Samsung devices running Knox Workspace 2.8 and higher

About this guidance 

This guidance is for Samsung Devices with Knox 2.8 and higher. It was tested on Samsung Galaxy S8 devices with Samsung SDS EMM as the Mobile Device Management (MDM) server.

It's important to remember that this guidance has been conceived as a way to satisfy the 12 End User Device Security Principles. As such, it consists of recommendations and should not be seen as a set of mandatory instructions requiring no further thought.

Risk owners and administrators should agree a configuration which balances business requirements, usability, and security.

For a list of CPA and CC approved Samsung devices and technologies, please see this list on the Samsung Knox website.

Knox workspace

The Knox Workspace is a secure container which separates data stored within it from the rest of the operating system. It provides additional security features, over and above those of the underlying Android platform. Users can store all or some of their enterprise data in the Knox Workspace, providing enhanced protection. A variety of approaches can be taken when using the Knox Workspace within an organisation. For example:

  • For users working primarily with sensitive data, the majority of their work will be within the Knox Workspace. The Android platform outside the Knox Workspace is used for non-sensitive work.
  • Users who only access sensitive data occasionally can use the Knox Workspace when they are required to work with that sensitive data, doing the non-sensitive majority of their work outside the container.
  • Enterprise applications and data should be kept within the Knox Workspace where possible. Unnecessary applications outside the container should be removed or managed using an appropriate whitelist.

Risk owners’ summary

We recommend the following architectural choices for Samsung devices with Knox 2.8:

  • All data-in-transit to and from the device should be routed over a secure enterprise VPN, to ensure the confidentiality and integrity of the traffic, and to allow the devices and data on them to be protected by enterprise protective monitoring solutions.
  • Users are not permitted to install arbitrary third-party applications on the device. An enterprise application catalogue should be used to whitelist and distribute approved applications to devices.

There are no significant risks to be aware of when using Samsung devices with Knox 2.8 configured in accordance with this guidance.

Administrators' deployment guide

Overview

To meet the principles outlined in the End User Devices Security Framework, several recommendations are given in the table below.

Security Principle

Recommendation and Explanation

Assured data-in-transit protection

Samsung provide a Knox compatible VPN client that should be used to route data via the VPN. This client gives three options for its VPN:

  • Knox workspace only VPN
  • Whole device VPN (excluding Knox workspace)
  • Whole device VPN (including Knox workspace)

One of these should be chosen and should have the VPN set to “Per-App” and to include “All Packages”, ensuring all application data within the desired scope is routed through the VPN. Choosing the container-only VPN allows less-trusted application data to be separated from the application data within the Knox Workspace - which could be treated as a security boundary for more sensitive information.

 

Assured data-at-rest protection

Data stored within the Knox Workspace is encrypted by default. Ensure Android's native data encryption is also enabled to protect data outside the Knox Workspace. The Knox native email client has been enabled to use the Sensitive Data Protection (SDP) feature.

Third party applications can take advantage of the SDP-protected "Chamber" folder to protect data while locked as well as when the device is turned off. Samsung also provide an SDK to enable applications to treat files as "sensitive", meaning they are protected by the SDP mechanism.

Authentication

The user should be required to authenticate to the device in line with your organisational policy (see Authentication Policy).

Your organisation's services should be configured to use X.509 client certificate authentication where possible. Devices should be provisioned with user-specific client certificates. The native mail client and browser can use these for authentication.

The authentication mechanisms chosen can be in the form of passwords, biometrics, swipe pattern, or PIN.

Each credential should be unique.

Secure boot

No configuration is required.

Platform integrity and application sandboxing

Knox 2.8 has several security features to verify the integrity of the phone software and hardware. Configure the MDM software to enable “Remote Attestation” to verify the integrity of the platform before creating the Knox Workspace.

The MDM client application is not verified by the Knox platform. A social engineering attack could result in a compromised MDM client being installed. To prevent this, device enrolment should only be performed by an administrator and users should not be permitted to re-enrol.

Application Whitelisting

Samsung Knox enabled devices allow a server to fully control applications both inside and outside the Knox Workspace, including maintaining an application installation whitelist.

Optionally, the administrator can allow the user to move applications installed on the personal side of the device into the Knox Workspace, or enable the use of Google Play in the Knox Workspace. If either option is enabled, the administrator can still control installation via whitelisting.

All enterprise applications should be deployed within the Knox Workspace.

Some MDM servers allow an enterprise application catalogue to be established, permitting users access to an approved list of applications via the MDM client. If the Play Store or Samsung Store is enabled, an MDM should be used to control and monitor which applications a user can install.

Malicious code detection and prevention

Where possible, an enterprise application catalogue can be used which should only contain vetted applications. If the Google Play or Samsung Store is enabled, a whitelist should be used to control which applications may be downloaded. Content-based attacks can be filtered by scanning capabilities in the enterprise. Applications hosted in the Google Play Store are scanned for potentially harmful or malicious activity prior to being made available for download.

Each application is protected by its own sandbox which is enhanced by controls such as SELinux and SECCOMP. Therefore, there is little additional value to be gained from any third-party anti-malware products in the platform.

Security policy enforcement

MDM software can be used to enforce security policies on both the device and Knox Workspace and prevent the user from altering security-related settings.

Not all MDM products support the full range of Knox and Android settings. Choose an MDM provider which supports the required configuration settings for your particular deployment to ensure they are applied securely. Please see Samsung's list of supported MDM vendors for details on which MDM supports which policy.

External interface protection

Wi-Fi, NFC, Bluetooth, SD cards, and the use of USB interfaces can all be disabled if not required. At a minimum, USB debugging should be disabled via policy.

Device Update Policy

MDM software can be used to audit which apps and OS versions are installed on a device. Some MDM servers may provide an application, OS, and Firmware update policy to ensure that apps are updated.

The user is responsible for installing Over-The-Air (OTA) updates, but the administrator can prevent OTA updates and view what OS version a user has installed via MDM. Enterprises can also use FOTA (Firmware Over-The-Air) to control how and when firmware updates are performed on devices. 

Event collection for enterprise analysis

The MDM server can be used to retrieve information from the device such as, installed applications, the last time the device has been seen by the MDM, policy compliance, and location information. The extent of the available event collection will depend on the MDM in use.

Additionally, some MDM servers support the additional Audit and Logging features which Samsung Knox adds to the Android platform. Logs created on the device, including failed unlock attempts, can be retrieved using an MDM which supports this feature.

Incident Response

Samsung Knox Workspace enabled devices support remote wipe when used in conjunction with a suitable MDM. This can be configured to selectively wipe the Knox Workspace, the device, or both, and uninstall the entire Knox Workspace. The SD card may also be wiped if configured in policy.

In addition to this, Samsung Knox Workspace enabled devices offer a device attestation mechanism, enabling the device to attest its integrity to the MDM, or include tamper incident logs which can be responded to.

Access to the enterprise network can be prevented by revoking the VPN client certificate associated with a lost or stolen device. Additionally, the client certificates for any other enterprise servers (such as email) that are stored on the device should be revoked.

 

Recommended on-premise network architecture 

It is recommended that all remote or mobile working scenarios use a typical remote access architecture based on the Walled Garden Architectural Pattern.

Configure the Samsung Knox Workspace enabled device’s global HTTP proxy so that it is used for both the device and the Knox Workspace.

 

Recommended on-premise network architecture

 

Preparation for deployment

For an enterprise deployment of Samsung Knox Workspace enabled devices, administrators should:

  1. Deploy and configure the requisite network components as described above.
  2. Procure and set up an MDM server that is compatible with Knox and is able to enforce the settings given in the Recommended policies and settings section below.
  3. Create MDM security profiles for the Samsung Knox Workspace enabled devices in line with the guidance given in the Recommended policies and settings section, and associate these profiles with the devices.

Recommended cloud network architecture 

It is recommended that all remote or mobile working scenarios use a typical remote access architecture based on the Walled Garden Architectural Pattern.

Configure the Samsung Knox Workspace enabled device’s global HTTP proxy so that it is used for both the device and the Knox Workspace.

For a comprehensive approach to the use of cloud based services, please refer to the NCSC's Cloud Security Principles suite of documents.

 

Recommended cloud network architecture

 

When using a Cloud MDM, it is recommended that access to Administrator accounts should only be permitted from dedicated devices, and that these only have access to the MDM website.

Preparation for deployment

For an enterprise deployment of Samsung Knox Workspace enabled devices, administrators should:

  1. Deploy and configure the requisite network components as described above.
  2. Procure and set up a cloud based MDM server that is compatible with Knox and is able to enforce the settings given in the Recommended policies and settings section below.
  3. Create MDM security profiles for the Samsung Knox Workspace enabled devices in line with the guidance given in the Recommended policies and settings section, and associate these profiles with the devices.

Device provisioning steps

Devices can either be provisioned manually by an administrator, or automatically if Knox Mobile Enrolment (KME) is used.

Manual provisioning

The following steps should be followed to manually provision each device onto the enterprise network, preparing it for distribution to end users.

  1. Install the MDM client on the device, and enrol the device into the MDM. The enrolment process will vary according to the MDM in use.
  2. Install the Knox compatible VPN client. This should be done via the MDM if possible.
  3. Push the MDM policy to the device. If the MDM does not allow configuration of any of the following via policy, it should be done manually:
    1. Install and configure the Knox Workspace.
    2. Configure on-device security settings.
    3. Install required user, device, and trusted CA certificates for the organisation on the device. MDM software may automate this process.
    4. Ensure that only trusted apps are installed and enabled on the device (disable or delete unnecessary apps both inside and outside the Knox Workspace, including Google Play and the Samsung Store).
    5. Ensure that all enterprise apps are installed inside the Knox Workspace. Apps outside the Knox Workspace should be restricted to basic functionality, and personal web browsing if desired.
    6. Configure a per-app VPN profile for all applications inside the Knox Workspace, either whole device including the container, or container only. This can be done with a single setting, and does not require each application to be set up individually to use the VPN.
    7. Configure the Knox email client to connect to the email server using client certificate or credential authentication.
    8. Configure the device’s global HTTP proxy so that it is used for both the device and the Knox Workspace.

Automatic provisioning

Provisioning can also be done automatically by using Knox Mobile enrolment (KME). This is designed to assist in the deployment of devices, and is able to provision devices in bulk.

To use KME, first sign up for a Samsung account, and request the service from their portal. Once activated, devices can be enroled in one of two ways:

  1. Bulk upload by Samsung or reseller of your choice. This means giving your chosen device retailer your KME ID, and means all the devices will be enroled into your KME account ready to be configured. Configuring in this case would involve creating an MDM profile to push to your devices, which has various details about your MDM.  
  2. Manually through the Samsung Knox Deployment app. This allows for existing devices to be enroled into KME. By using the Knox Deployment app on a separate device, you can enrol a pre-existing device into KME via NFC.

Using KME ensures that end users will only be required to do minimal setup of the device.  

For more information on how to do this please see this mobile enrolment article on the Samsung Knox website.

Recommended policies and settings

The following settings should be applied from the MDM interface. As all MDMs vary, the text accompanying the setting may be slightly different to that shown below. The policies given below are taken from Samsung SDS EMM.

Knox Workspace policies

The following policies should be applied to the Knox Workspace.

Configuration Rule

Recommended Setting

Allow applications to be moved into the Workspace

<Knox Workspace Name> → Policy → Container Data → Moving an application to the container

Enable.

Applications that can be moved into the container are restricted by the whitelist.

Whitelist Applications

<Knox Workspace Name> → Policy → Application → Application black/whitelist settings

Whitelist essential applications for accessing and manipulating corporate data only, e.g. email client, browser, and productivity suite. If the Samsung Store or Google Play stores are permitted, allow only applications in the whitelist to be installed.

Browser

<Knox Workspace Name> → Policy → Browser → Android browser

Enable.

VPN

<Knox Workspace Name> → Settings → Generic VPN

Apply the Per-App VPN to all applications in the Knox Workspace, including background services and widgets.

Email

<Knox Workspace Name> → Settings → Email Account

OR

<Knox Workspace Name> → Settings → Exchange ActiveSync

Configure the email client to connect to the email server using client certificate or credential authentication.

Email account addition

<Knox Workspace Name> → Settings → System → Domain whitelist setting

Add the domains you wish to whitelist.

Other MDMs are capable of disabling this option without a whitelist.

This prevents users adding additional email accounts within the Workspace.

HTTP Proxy

<Knox Workspace Name> → Settings → Generic VPN → Forwarding route

Set the enterprise proxy as both the device and Knox proxy. This will prevent network traffic which is not configured to use the VPN reaching the Internet.

Password

<Knox Workspace Name> → Policy → Security → Password Policies

Your organisation should have a consistent authentication policy which applies to all users and devices capable of accessing its data. You can use our published password guidance to help inform any password policy.

The authentication mechanisms chosen can be in the form of passwords, biometrics, swipe pattern, or PINs and should adhere to the model of having the user authenticate once to the device, and then again to access the sensitive data within Knox.

Each authentication method should be unique.

Credentials

 

Some certificates can be installed via policy, VPN, email, etc.  However, other certificates need to be sent to the device then manually moved to the Knox area.

Permit moving files into the Knox Workspace

<Knox Workspace Name> → Policy → Container Data → Moving a file to Knox area

False.

Permit moving files out of the Knox Workspace

<Knox Workspace Name> → Policy → Container Data → Moving a file to General area

False.

Knox Workspace data synchronisation

<Knox Workspace Name> → Policy → Container Data 

The following settings should be set to ‘disallow’ to prevent data being moved into and out of the Knox Workspace:
- Preview Knox notifications
- Export contacts to personal mode
- Export calendar items to personal mode

Hardware strengthening

Samsung's S8 devices are required to implement a hardware-backed keystore. This means that successful authentication is required to use dedicated hardware (normally a Trusted Execution Environment, or TEE), and this prevents offline brute force attacks against data-at-rest keys. However, this mechanism does not prevent online attacks from privileged malware running on the device.

Biometrics

Samsung's S8 devices are required to perform biometric checking within a Trusted Execution Environment (TEE). This means that a physical attack on a locked device should not result in compromise of data. Fingerprint readers are required to have less than 0.002% false acceptance rate, but the performance of individual sensors can vary within that range. You should consider these limitations when devising an authentication policy which permits the use of biometrics.

Samsung Knox Workspace enabled device policies

The following policies should be applied outside the Knox Workspace. These settings will promote use of the Knox Workspace and secure residual data and activity outside the Knox Workspace.

Configuration Rule

Recommended Setting

App stores

Android → Policy → Application → Google Play 

Disable or remove the Google Play and Samsung App store, and prevent the installation of applications from unknown sources.

Whitelist Applications

Android → Policy → Application → Application black/whitelist settings

Disable or remove unnecessary applications. If the Google Play or Samsung App stores are permitted, allow only applications in the whitelist to be installed.

Developer Mode

Android → Policy → System → Allow developer mode

Prevent all developer mode settings, including USB debugging and USB storage mode.

Encrypted storage

Android → Policy → System → Encryption for storage

Enforced internal encryption.

SD card

Android → Policy → System → External SD card

Disable access to the SD card.

HTTP Proxy

Android → Settings → Generic VPN → Forwarding route

Set the enterprise proxy as both the device and Knox proxy. This will prevent network traffic which is not configured to use the VPN reaching the Internet.

Password

Android → Policy → Security → Password Policies

Your organisation should have a consistent authentication policy which applies to all users and devices capable of accessing its data. You can use our published password guidance to help inform any password policy.

The authentication mechanisms chosen can be in the form of passwords, biometrics, swipe pattern, or PINs and should adhere to the model of having the user authenticate once to the device, and then again to access the sensitive data within Knox.

Each authentication method should be unique.

Lock timeout

Android → Policy → Security → Time to Lock Screen

10 minutes.

VPN

Android → Settings → Generic VPN

Apply the Per-App VPN to all applications outside the Knox Workspace, including background services and widgets.

Certificates

Android → Policy → Security → Certificate verification when installing

Enable certificate validation at install.

Install enterprise certificates (including VPN certificates and organisation CA certificates).

Interfaces

Android → Policy → Interface

Disable unnecessary interfaces, e.g. USB interface, Bluetooth, NFC as required.

Attestation

Android → Policy → Security → Attestation

Verification of Knox attestation status should be required.

Samsung SDS EMM also automatically enables CC Mode, TIMA Key Store, and ODE Trusted Boot Verfication. If you are using a different MDM, check that these policies are enabled by default, or enable them manually if not.

VPN configuration

The built-in VPN client should be configured for Samsung Knox using a compatible MDM, and configured with the PSN End State IPsec profile in the CPA Security Characteristic. Samsung provide guidance on how to set up the Knox VPN Client.

This VPN profile should be applied as a Per-App VPN to applications on the device, in either Container only VPN or Full device VPN - including the Knox container. A ‘Per-App’ profile does not require each app to be individually configured to work with the VPN, it causes the VPN to start automatically and all app traffic to be routed via the VPN tunnel. 

The following configuration is recommended, with all other fields left as default:

VPN vendor name StrongSwan
VPN type IPSec
User authentication

Do not use

User certificate input method EMM Management Certificate
User certificate <Select relevant certificate from uploaded certificates>
CA Certificate <Select relevant certificate from uploaded certificates>
Connection type IPSec IKE2 RSA (Supports CC mode)
VPN route type by application All Packages

Enterprise considerations

The following points are in addition to the common enterprise considerations, and contain specific issues for deployments of Samsung Knox Workspace enabled devices.

Choice of MDM provider

Not all MDM solutions are capable of interacting with all Knox APIs. It is essential that system architects evaluate which policies their MDM solution will enable them to set, and should note that at the time of writing no MDM solution can set all Knox policy types.  Please see this list of supported vendors on the Samsung Knox website for details on which MDM supports which policy.  

MDM solutions that cannot set the policies specified in the Recommended policies and settings section should not be considered for use. Specifically, enabling CC mode requires either an MDM which supports the feature or installation of an Android application onto each device to enable the mode. 

Many MDM providers now offer cloud-based solutions. Organisations that wish to use cloud-based MDM products must take into consideration the risk of placing the security and control of their devices and data under a third party. 

Was this guidance helpful?

We need your feedback to improve this content.

Yes No