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 Wipe 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 USB debugging 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 Wipe option has been enabled under Basic Integrity failure action.
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 the policy has been assigned to the users, a red traffic light will be displayed in the Cortado app (left illus.) and the Delete all data option in the settings is greyed out (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 management console. 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 Wipe (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 USB debugging 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 USB debugging to be enabled. As the "debugging functions" 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 Wipe (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. You can use the policy to either run the updates immediately or you can postpone them for up to 30 days. 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 non-market apps. In this instance, make certain that the policy Ensure verify apps 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 management console, 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 use the Config credentials policy Config credentials. 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 blacklist.