Preventing rooting of Android devices
Preventing a device from being restored to factory defaults via the device settings
Preventing reconfiguration after a hard reset
Preventing the installation of customised OS versions
Preventing installation of apps that don’t come from the Play Store
Preventing installation of untrusted certificates
Preventing unintentional browsing on phishing websites
Preventing rooting of Android devices
With regard to Android, rooting refers to the process by which a root account (Superuser) gains access to the complete system, including all the resources. Root access is consequently disabled by default on all Android devices. Rooted devices are not desired in a corporate environment, because company data can be revealed on those devices. It must therefore be ensured that no devices that have previously been rooted can gain access to corporate applications or services. Additionally, retrospective rooting of previously registered devices must be prevented.
Two actions are required for this:
- Configure Google’s SafetyNet Test. Under Basic Integrity failure action enable the Reset option. As soon as SafetyNet Test detects a rooted device, it will reset it to factory default settings. This will prevent rooted devices from being registered.
- The second security measure is already enabled by default. Users are denied access to the developer options on fully-managed Android devices. (If required, you can use the policy Allow use of developer options to change this default setting. For the reasons stated above, however, this is not recommended.)
Android devices can only be rooted if the bootloader is unlocked, which requires USB debugging to be enabled. Rooting the device is prevented because the "debugging functions" are restricted by default. However, in very rare cases, a vulnerability in the operating system version can lead to some applications gaining root access on the device even without USB debugging being enabled. In such a case, Google’s SafetyNet Test will take effect, provided the Reset option has been enabled under Basic Integrity failure action.
Preventing a device from being restored to factory defaults via the device settings
If you want to prevent a user from being able to restore their device to factory default settings via the device settings, set up a corresponding policy.
After assigning the policy to the users, the new setting is displayed in the Cortado app (left illus.) and the action is not possible in the settings (right illus.).
It is now no longer possible to reset to factory default settings via the device settings.
Preventing reconfiguration after a hard reset
It is possible to use the power and volume control buttons on Android devices to reset to factory default settings. This hard reset cannot be prohibited via a policy. However, it is possible to prevent the reconfiguration of a device that has been reset in this fashion. With Android 5.1, Google introduced the so-called Factory Reset Protection (FRP) for this purpose. Use the Factory Reset Protection (FRP) policy to enable FRP in the Administration Portal. On devices with FRP, reconfiguring after a hard reset requires the entry of the most recently used Google account, with password. With this in mind, in the FRP policy you can store up to three Google accounts (of administrators) that can be used instead.
Preventing the installation of customised OS versions
There are a variety of reasons why users may wish to use a customised version of the Android operating system. Such versions could, for example, make available an additional feature that is not present in the official version. Or users may want to get out of the version of the operating system supplied by a particular provider (T-Mobile, Verizon). It could also be that there is an intention to install a recovery image that would make it possible for the device to be rooted. To protect corporate data, it must be ensured that access is denied to all devices with customised OS versions. And retrospective changes to the OS version on already registered devices must also be prevented.
Two actions are required for this:
- Configure Google’s SafetyNet Test. Under CTS Profile Match failure action, enable the Factory reset (or Lock) option. As soon as SafetyNet Test detects a device with an unofficial operating system, it will be reset to factory default settings (or locked). This will prevent those devices from being registered.
- The second security measure is already enabled by default for Android devices. Users are denied access to the developer options on fully-managed Android devices. Therefore, no changes can be made to the operating system. (If required, you can use the policy Allow use of developer options to change this default setting. For the reasons stated above, however, this is not recommended.)
A customised operating system can only be installed if the bootloader is unlocked, which requires developer options to be enabled. As the "developer options" are restricted by default, the devices are usually secure. However, in very rare cases, a vulnerability in the operating system version can have undesired effects. In such a case, Google’s SafetyNet Test will take effect, provided the Factory reset (or Lock) option has been enabled under CTS Profile Match failure action.
Installing security patches
In the past, security vulnerabilities have been repeatedly identified in versions of Android. Therefore, device manufacturers and Google release monthly security patches. It is always recommended to keep security patches up to date. Use the OS Update policy, to force the installation of OS updates. Schedule the updates to run during work-free hours.
Preventing installation of apps that don’t come from the Play Store
All Play Store applications are checked by Google to ensure they have no security vulnerabilities and that they contain no malware programs. However, .apk files that are installed directly onto a device certainly can contain security vulnerabilities and malware programs. Therefore, Cortado prohibits by default the installation of applications that don’t come from the Play Store. You don’t need to make any additional settings.
If you wish, nevertheless, to allow your users to install applications that don’t come from the Play Store, but still ensure that they pose no threat, distribute the policy Allow installation of apps from unknown sources. In this instance, make certain that the policy Enforce app scanning for malware is also enabled. All those apps will then be scanned for vulnerabilities.
Locating missing devices
Mishaps can occur at any time. If a user is missing a device, it could be misplaced, lost or have been stolen. With the Cortado Administration Portal, you can attempt to find it again. Lock the device by activating lost mode, leave a message on the lock screen and try to relocate it.
Preventing installation of untrusted certificates
Installing an untrusted CA certificate creates an opportunity for a man-in-the-middle attack. You can uncheck the Allow changes to security certificates policy. to prevent this. Remove the check mark from the checkbox and distribute the policy to your users.
If you want to use self-signed certificates for apps in your organisation, create a certificate profile for distributing the certificates.
Preventing unintentional browsing on phishing websites
Phishing websites attempt to obtain users’ login data. If a user inadvertently visits such a website (e.g. via a link in a phishing email), corporate data can fall into the wrong hands. You can prevent that happening with the help of Managed Configurations for the Google Chrome and Microsoft Edge browsers. To do so, activate the Disable proceeding from the Safe Browsing warning page checkbox in Managed Configurations of the respective app.
Make sure that all other system browsers on the device are on the blocking list.