Guidance

Good for Enterprise and Good Dynamics: Security Guidance

Published 18 November 2013

1. About this guidance

1.1 Who is this guidance for?

This guidance is for UK Public Sector organisations, their agencies and their suppliers who are considering deploying Good for Enterprise and/or Good Dynamics, both of which are developed by Good Technology. It is written for system administrators and information risk owners responsible for deploying End User Devices (EUDs) for remote working at OFFICIAL.

Readers are expected to be familiar with the operation and functionality of Good for Enterprise and/or Good Dynamics in addition to the EUD Platform Security Guidance, which this guidance builds on.

1.2 What is this guidance?

The End User Device Security Framework outlines a number of security requirements that must be met as part of any mobile working strategy at OFFICIAL. Many of these requirements can be met by deploying and configuring EUDs appropriately, in accordance with the EUD Platform Security Guidance. Where security requirements cannot be met by the native platform, organisations must either accept the residual risk or mitigate it using additional solutions.

For this reason, organisations might consider a ‘container’ application that creates a separate, enterprise-managed area on an EUD. CESG have performed a short assessment of the features provided by Good for Enterprise (GFE) and Good Dynamics (GD) and this security guidance describes the key risks of using them to access OFFICIAL information on EUDs. Recommended actions are provided to help organisations make informed risk-management decisions but this guidance does not represent an endorsement or certification.

Although GFE and GD are often proposed as secure solutions for BYOD deployments they are reliant on the underlying platform being secure; they cannot add trust where none exists. Devices must be corporately managed and should be deployed in accordance with the EUD Platform Security Guidance.

1.3 What is Good for Enterprise?

GFE is an application suite which aims to protect a device’s email, contact information and calendar, in addition to providing a secure browser and camera. This is done by creating an enterprise-managed container that allows technical controls to be enforced in the absence of ones provided by the underlying platform.

GFE can also provide MDM functionality, which can be used to support the requirements of the EUD Platform Security Guidance. The MDM feature set has not been explicitly assessed for this guidance although it is occasionally referenced.

1.4 What is Good Dynamics?

GD refers to two similar solutions from Good Technology; a Software Development Kit (SDK) and an application ‘wrapping’ toolkit.

The SDK can be used by independent software vendors (ISVs), as well as Good Technology, to create mobile applications. GD-secured applications are able to take advantage of the storage and networking APIs provided by the SDK (instead of the native platform) to encrypt data-at-rest and data-in-transit. The SDK also provides an enterprise with controls over specific application behaviour, such as copy-and-paste functionality and data transfer between applications.

When using the wrapping toolkit, Good Dynamics provides a subset of the SDK features by modifying the application binary after it has been compiled to make use of the GD APIs. This does not require any code changes by the application developer.

2. Summary of key risks

The key risks, which are likely to impact a decision to use GFE and/or GD, are summarised below for busy readers. Additional risks are detailed further in the document.

  1. Without confidence in the underlying platform, applications cannot add extra security. If a device is compromised by malware then the protection offered by the GFE client and GD-secured applications can be circumvented and sensitive information would be accessible. For this reason it is important to ensure that appropriate protection is provided to the device as a whole, as well as to applications. In order to adequately protect OFFICIAL information, organisations should follow the guidance provided in this document and the EUD Platform Security Guidance.
  2. All network data transferred from the GFE client and GD-secured applications and the enterprise is routed via the Good Network Operations Centres (NOCs), located in the United States. Although user data is encrypted such that it is not accessible to the NOC, metadata about the enterprise is. An adversary with access to the NOC would be able to discover:
    • GFE-registered users’ email addresses
    • which devices are registered to an enterprise
    • what Good-enabled applications (the GFE client and GD-secured applications) are installed on devices
    • the enterprise domain name(s) that the GMC, GMM, GC and GP servers are connected to
    • the names of user accounts used to set policy on the GMC control panel
  3. The GFE client is contained within a single sandbox; there is no isolation between internal components (such as the email client and web browser). An adversary who is able to exploit a vulnerability in one component would be able to access all data stored within the GFE client. When using the GFE client as the Authentication Delegate (for single sign on) this would also include the encryption keys for GD-secured applications.

Good for Enterprise and Good Dynamics are solutions that consist of several components. Although advice for the installation and configuration of GFE and GD is available from Good Technology, this section discusses how an organisation can align this with both the EUD Platform Security Guidance and the Walled Garden Architectural Pattern (available from the CESG IA Policy Portfolio).

Technical details, such as which ports are used by the servers, can be found in Good Technology’s documentation and have not been included here.

3.1 Good for Enterprise components

GFE consists of five components:

  • Good for Enterprise client application (installed on an EUD)
  • Good Technology’s NOC
  • Good Mobile Control (GMC) server
  • GMC database
  • Good Mobile Messaging (GMM) server

The GMC server manages users, devices and policies while the GMM server acts as a relay between the GFE client and an enterprise’s email servers. The GMM server also proxies web traffic from the GFE client to intranet web applications. The GMC database is an SQL database that stores all policy, configuration and container information. It can be installed on the GMC server or a separate SQL server. Organisations can deploy multiple GMC and GMM servers for load balancing.

3.2 Good Dynamics components

Good Dynamics consists of six components:

  • the Good Dynamics SDK
  • an application built with or wrapped with the Good Dynamics SDK
  • Good Technology’s NOC
  • Good Control (GC) server
  • GC Database
  • Good Proxy (GP) server

The GC server manages users, devices, policies and GD-secured applications while the GP server is used to route network traffic from GD-secured applications to enterprise services. The GC database is an SQL database that stores all policy, configuration and container information. It can be installed on the GC server or a separate SQL server. Organisations can deploy multiple GC and GP servers for load balancing.

3.3 Common principles

Where possible, organisations should reuse existing infrastructure rather than install duplicate systems solely for GFE and/or GD. Network traffic between the Good NOC and the GFE / GD enterprise servers should be routed through existing protective monitoring solutions.

The underlying server platforms are expected to be configured in accordance with good practice, such as ensuring timely patching and creating accounts with the minimum necessary privileges. File access controls should be set for configuration files such that sensitive settings are protected. Refer to departmental or CESG policy for specific implementation notes.

As part of giving accounts the minimum necessary privileges, the Windows service accounts required for the GFE and GD enterprise servers (the ‘GoodAdmin’ account by default) should be prevented from logging into workstations. While more complex to initially configure, using Managed Service Accounts (available from Windows Server 2008 R2 onwards) can simplify service administration and provides increased security over that provided by a Domain User account.

Digital certificates used by the GFE and GD enterprise servers should be chained to the enterprise’s existing CA instead of using the self-signed certificates generated during installation.

No inbound firewall exceptions are required on the external firewall as the installed servers initiate outbound TLS connections to the Good NOC. Outbound firewall rules should be added if necessary.

This architecture aims to limit the impact of a compromise of an EUD and isolate high risk components from high value components where possible. The enterprise servers installed as part of GFE and GD are high value resources that require suitable protection but are also high risk; they perform complex processing tasks that are more likely to contain exploitable vulnerabilities. These competing properties make securely placing the servers into an existing network challenging and organisations that wish to deviate should ensure they understand the risks of doing so.

Since GFE and GD are architecturally similar, components from both solutions are represented on a single diagram and discussed in parallel. Where the solutions differ, this is highlighted.

Recommended network architecture
Recommended network architecture for GFE and GD deployments

Network traffic from the GFE client and GD-secured applications is always routed to the Good NOC. The GMM and GP servers each maintain a persistent TLS connection to the NOC which the NOC uses to route traffic. So that the NOC cannot access user data, it is further encrypted with keys not known to the NOC.

As network traffic is encrypted between EUDs and the GMM / GP servers, protective monitoring solutions will not provide meaningful results unless analysing traffic that has been decrypted on the GMM / GP servers.

The GMM and GP servers should be deployed in the presentation layer of the enterprise network to minimise the exposure of core networking services and limit access to those services that are explicitly required for GFE and GD to function. The GMM and GP require access to application servers, such as email. Where possible, organisations should make use of existing mediation services in the presentation layer (such as a reverse proxy or mail edge transport server) rather than add additional firewall rules to the internal firewall to permit access to services within the core network.

The GMC and GC servers should be deployed in the core of the enterprise network to protect them from malfeasance. Firewall rules will need to be added to the internal firewall to allow the GMM and GP to communication with the GMC and GC servers.

The provisioning terminals for the GC and GMC servers are used to configure the policies and MDM settings for EUDs. The terminals need not be dedicated machines as the GMC and GC configuration panels are available via a web interface.

Since the EUD Platform Security Guidance expects a VPN to be used for remote access, this is included as part of the recommended architecture. It is possible to deploy GFE and/or GD without a VPN, as shown below but organisation should read the Data-in-transit protection section to understand the risks of doing so.

Alternative network architecture without a device VPN
Network architecture for GFE and GD deployments without a device VPN

4. Technical assessment

4.1 Summary of application security

The EUD Security Framework describes twelve areas for security controls for devices, each of which must be considered when deploying a particular solution. The EUD Platform Security Guidance goes on to detail how several specific platforms meet or fall short of these controls.

The following table highlights how using GFE and/or GD impacts the 12 tenets on an EUD configured in line with the guidance, although these only apply to Good-enabled applications installed, rather than the whole device. Further technical details are provided in the following sections.

Security tenet Impact
1. Assured data-in-transit protection The GFE client enforces encryption of data-in-transit that cannot be disabled by an end user but this has not been independently assured to Foundation Grade. GD-secured application developers can choose to bypass this.
2. Assured data-at-rest protection The protection is reliant on the native platform providing suitable controls.
3. Authentication Additional authentication of interactive users can be enforced to control access to application data.
4. Secure boot GFE and GD do not provide functionality for this security control. Protection is reliant on the native platform.
5. Platform integrity and application sandboxing The GFE client is contained in a single sandbox such that a compromise of one internal component would give access to all protected data.
6. Application whitelisting Organisations control provisioning of Good-enabled applications and can control which of these applications can share information.
7. Malicious code detection and prevention The GFE and GD compliance manager cannot reliably provide proof of no malware. Protection is reliant on the native platform.
8. Security policy enforcement GFE and GD do not provide functionality for this security control. Protection is reliant on the native platform.
9. External interface protection GFE and GD do not provide functionality for this security control. Protection is reliant on the native platform.
10. Device update policy The GFE client and GD-secured applications can check for compliance with enterprise policies and can lock or wipe themselves.
11. Event collection for enterprise analysis The GFE and GD enterprise servers provide limited information for analysis.
12. Incident response The GFE client and GD-secured applications can be configured to lock or wipe themselves if an incident is detected.

4.2 Data-in-transit protection

The GFE client and GD-secured applications typically transmit network traffic to the Good NOC. Using metadata in the traffic, the NOC identifies which enterprise the traffic is destined for and forwards it. In order to prevent the NOC accessing sensitive user data, application data is further encrypted using secrets generated on the GMM server, which are not known to the NOC. For GFE, this inner layer of encryption uses AES-192. GD uses AES-256.

The encryption does not meet some of the mandatory requirements expected from assured TLS VPNs. Without assurance in the data-in-transit protection, there is a risk that data could be compromised.

Although the GFE client cannot circumvent this protection, GD-secured applications can choose to directly communicate with Internet services, without network traffic being routed via the NOC. In such cases, the protection of network traffic is dependent on the application’s own functionality, not the GD framework.

Although devices following the EUD Platform Security Guidance are expected to use a VPN, the network traffic from the GFE client and GD-secured applications does not benefit from the protection it provides; all GFE and GD network traffic must transit the Good NOC. Since this traffic does not benefit from the use of a VPN, GFE and GD traffic is not required to make use of a device VPN. A VPN still provides secure enterprise routing and protective monitoring of the device and other applications.

Recommendation: Unless confident that sensitive data will never be stored or accessed from outside the GFE client and/or GD-secured applications, and the risks of not protectively monitoring all device network traffic are acceptable, organisations should use a device VPN.

4.3 Data-at-rest protection

The GFE client and GD-secured applications protect data-at-rest on an EUD by storing it in an encrypted container. GFE uses AES-192-CBC encryption for this while GD uses AES-256-CBC. This has not been independently assured to Foundation Grade.

The encrypted container sits on top of the EUD filesystem therefore the security of the encrypted data on a device is linked to the strength of the user’s GFE / GD passphrase(s) (users can have multiple passphrases for different GD applications) and the protection provided by a device passphrase. On iOS devices the container uses Data Protection class C which provides dedicated hardware protection. The GFE / GD passphrase(s) can therefore be reduced in length and complexity on iOS devices.

To avoid users being required to enter their passphrase every time they open an application, a timeout period can be configured by the enterprise; sensitive user data is not protected during this timeout period. A shorter timeout period will decrease the opportunity for an adversary to access sensitive information but is likely to impact user experience.

Recommendation: The passphrase for GFE and GD-secured applications should be different from the device passphrase and handled in line with organisational policy. The EUD Platform Security Guidance contains advice on appropriate policy.

Recommendation: When deciding on an appropriate timeout period, departments should balance user experience against security. The timeout period should be no longer than 15 minutes.

4.4 Web content protection

The GFE client provides a web browser, known as Good Mobile Access (GMA). GMA protects browser, cookie and Adobe Flash data on the device by overriding the default platform storage methods with methods that make use of the GFE client’s encrypted container. This data is not available to other applications unless they are built with Good Dynamics and access is permitted by enterprise policy.

GMA does not override the W3C Web Storage APIs (commonly known as HTML5 localstorage), which websites may use to store user data. This is also true for GD-secured applications which make use of these APIs or are built with HTML5 frameworks that make use of them. Information stored using these mechanisms is not protected. As with all web browsers, malicious or compromised websites may be able to exploit a vulnerability in GMA in order to access sensitive data.

Recommendation: Organisations should ensure that web applications accessed with GMA and GD-secured applications do not store sensitive data using the Web Storage APIs.

Recommendation: Good Mobile Access should be configured to only allow access to intranet websites and applications to limit the exposure to malicious websites.

4.5 Malicious code detection and prevention

Jailbreaking (or rooting) is the act of exploiting a vulnerability in the operating system to disable various security restrictions, typically to allow unofficial modifications or applications to be used. This is equivalent to what malware often tries to achieve.

GFE and GD have a compliance management feature which can be configured to attempt to detect when a device has been jailbroken or rooted and can optionally take remedial action, such as wiping the device. Limitations of current technology mean that this ‘device status’ check is not sufficient to verify ‘known good’; malware can easily subvert such a check.

Recommendation: Administrators should enable jailbreak detection and configure the GFE client and/or GD-secured applications to wipe application data when this is detected, but must understand that it can be defeated by malware.

4.6 Document import and export

The GFE client and GD-secured applications can be configured to allow data to be imported and exported from other applications. These controls can help an enterprise manage which applications are able to access sensitive data.

While an enterprise may be more concerned with preventing documents being exported from these applications, imported documents could contain malicious content that attempts to extract sensitive information from the GFE client or a GD-secured application. If it is transferred from the application onto other enterprise infrastructure, such as a file store, the malicious content may not be scanned and could attack the enterprise network.

Recommendation: If document importing is permitted, ensure that imported documents are not able to circumvent existing protective monitoring solutions. The recommended network architecture is designed to limit the impact of such attacks on the enterprise infrastructure.

4.7 Temporary Unlock Code (TUC)

GFE and GD-secured applications can be unlocked via a temporary unlock code, which is generated during application provisioning and stored within the GMC or GC database. This unlock code is used to unlock the GFE/GD application in the event of a forgotten passphrase and should be protected to the same degree as the user passphrase. If an enterprise is planning on allowing the temporary unlock code to be provided remotely by a help desk, callers must be manually authenticated prior to providing the key.

4.8 GFE application sandboxing

To limit the information and functionality available to an application, many platforms provide an application sandbox. If an application is malicious or compromised, an adversary is unable to access information outside the sandbox without exploiting a weakness in the sandbox.

Since the GFE client is contained within a single sandbox, there is no isolation between internal components (such as the email client and web browser). An adversary who is able to exploit a vulnerability in one component would be able to access all data stored within the GFE client.

When using the GFE client as the Authentication Delegate this data would also include the encryption keys for GD-secured applications such that the adversary could access all information protected by Good-enabled applications.

Recommendation: Organisations should carefully consider what Good-enabled applications to install.

4.9 GFE address book synchronisation

The GFE client provides its own address book, which is stored within the GFE client. This data is not available to other applications unless they are built with the GD framework, and access is permitted by enterprise policy.

The GFE client can synchronise this contact information into the native contact store, for example to allow the platform to display the name of who is calling. Enterprises can configure which information is synchronised (such as name, phone number, email address, notes, address etc.), permitting a more granular level of information disclosure.

Recommendation: Organisations should consider which fields within the address book are sensitive, and configure the synchronisation policy accordingly.

4.10 GFE calendar alerts

The GFE client provides its own calendar, which is stored within the encrypted application container. This data is not available to other applications unless they are built with the GD framework, and access is permitted by enterprise policy.

When a reminder is set for a calendar appointment and this reminder is triggered, the GFE client triggers a device popup message. This message can either display the appointment details or use a generic alert instructing users to open the GFE client for actual appointment details.

Recommendation: Organisations should consider whether calendar appointment information is sensitive, and configure the calendar alert policy accordingly.

4.11 GD application protection

Good Dynamics is designed to provide application developers with a cross-platform set of security features. The security offered by Good Dynamics is reliant on correct use of the framework by ISVs, although GD-secured applications are required to undergo testing prior to publication. This testing is designed to identify any errors in the use of the GD framework so it does not cover the application’s business functionality, which may be otherwise insecure or malicious.

Good Dynamics can also be used directly to ‘wrap’ application binaries with minimal involvement from an ISV. This requires Good Technology to dynamically identify application code that is writing content to a disk or network and modify the behaviour to use the GD-provided functionality. There is a large and changing list of APIs that Good Technology must cover to ensure sensitive data is protected; failure to identify all the necessary APIs could result in data not being protected by GD. Wrapped applications can still contain malicious functionality.

Recommendation: Administrators should not install arbitrary applications, even if built with the GD framework, and should still perform due diligence testing to satisfy themselves that applications do not contain malicious functionality.

4.12 GD framework updates

Updates to the GD framework are not applied to installed GD-secured applications directly. Applications must be recompiled with the updated framework by the developers and then deployed to devices. Applications not using the latest version of the GD framework may be vulnerable to attacks that have been mitigated by newer versions of the framework.

Recommendation: Departments should ensure provisioned GD-secured applications make use of recent updates to the GD frameworks.

4.13 Network Operations Centre

Good Technology runs two NOCs in the United States that act as relays between EUDs and the GFE and GD enterprise servers. User data is encrypted using secrets not known to the NOC.

The NOC’s role as a communications broker between the EUD and the enterprise means that it helps to protect the exposed enterprise services against a network attack. Despite this, the NOC is still in a privileged position, it is able to:

  • prevent the relaying of network traffic between the client and enterprise servers, denying service to users
  • identify which devices belong to an enterprise and what Good-enabled applications are installed
  • access the metadata of network traffic, including:
    • GFE-registered users’ email addresses
    • the enterprise domain name(s) that the GMC, GMM, GC and GP are connected to
    • the names of user accounts used to set policy on the GMC control panel

Recommendation: Organisations should understand what metadata is available to the Good NOC, identify whether it is sensitive and ensure they have sufficient trust in Good Technology to protect it. They should also establish that the service availability levels meet their requirements.

4.14 Mobile device management

GFE can provide MDM functionality through the GMC server. This functionality has not been reviewed and organisations should perform their own assessment as they would for any MDM provider.

Although the GMC server is installed within the enterprise network and policies are configured locally, MDM profiles are stored in the Good NOC. The GFE MDM functionality should be treated as a cloud MDM service. Anyone with access to the NOC would be able to manage devices on behalf of the enterprise, and could change security policies or unlock or remote-wipe a device. They would also be able to recover provisioned credentials stored within an MDM profile.

Recommendation: Organisations should ensure they have sufficient trust in Good Technology to manage devices on their behalf and protect the NOC from malfeasance.

4.15 Protection of the Over-The-Air (OTA) PIN

To activate the GFE client and GD-secured applications, users are issued with a PIN (respectively, the OTA PIN and GD access key). This PIN is generated by the GMC or GC server and registered against the provisioned user, although it is not tied to a specific device. The PIN can then be distributed to a user manually or via an automatic email.

For Good Dynamics, the PIN can only be used to provision one application on one device, it cannot be reused. The PIN can also be set to expire after a configurable time period if it is not used. For GFE, an expiry time can also be set however the PIN can be reused by default. Reuse can be disabled by policy.

Compromise of the PIN prior to its use would compromise the confidentiality of all data-in-transit from the provisioned application(s) as an adversary would be able to man-in-the-middle the connection.

Recommendation: The OTA PIN should always be handled in accordance with the classification of data that the application will handle. If the PIN is sent to a user by email, the user should be reminded of the importance of keeping it protected and not allowing it to be passed to others.

Recommendation: Users must be trusted to use the PIN on the expected device or organisations should consider an Administrator provisioning GFE and/or GD-secured applications as part of a device provisioning process.

Recommendation: Organisations should disable OTA PIN reuse.

5. Other considerations

Prior to deploying GFE or GD-secured applications, a number of other risks that are not directly addressed in this report should be further explored by organisations. These are covered below.

5.1 DirectConnect

Good Technology will be releasing a new feature for Good Dynamics in late 2013 known as DirectConnect. When configured by an enterprise, GD-secured applications will be able to transmit application data directly to the enterprise network, without transiting the NOC. Administrative actions, such as application activation and policy enforcement, would still be routed via the NOC.

DirectConnect does not improve or weaken the current data-in-transit protection but does allow an organisation to rely instead on an assured VPN to wrap the GFE and GD traffic. It also reduces the latency for GD-secured application data as it no longer needs to be routed via the Good NOC.

5.2 Good Vault

Good Vault is Good Technology’s solution for user authentication using smart cards. It is a GD-secured application that uses a smart card instead of a user passphrase to protect encrypted information. It is intended to be used as the Authentication Delegate for a single sign-on solution, with the encryption keys for the GFE client and GD-secured application stored on the smart card. If used, organisations should ensure that the smart cards they use are able to provide suitable protection of the encryption keys.

It should also be noted that because the encryption keys are stored on the smart card itself, if the smart card is lost or stolen, the encryption keys to unlock GFE and GD-secured applications will also be lost. Users will not be able to access or recover data within the applications.

5.3 Security control availability

GFE and GD provide a range of controls that an organisation can make use of. Some of these controls apply to the GFE client or a GD-secured application while some are applied via the platform’s MDM capabilities. Organisations should ensure they understand which controls apply to the GFE client and GD-secured applications, and which apply to the MDM functionality.

5.4 Logging

GFE and GD contain logging functionality that reports diagnostic information to Good Technology from the GFE client, GD-secured applications and the enterprise servers. Organisations should disable it unless they are confident log data will never contain sensitive data.

5.5 GMM server communications

The GMM server communicates with an enterprise’s mail servers. For Microsoft Exchange, it currently supports both the MAPI and EWS protocols. As a more modern and secure protocol, EWS is recommended over MAPI.

Help us improve GOV.UK

Please don't include any personal or financial information, for example your National Insurance or credit card numbers.