# Welcome Secure OS is a security-hardened operating system based on Android. Secure OS is engineered to defend against the most sophisticated mobile cyber threats. ### Key features **Zero-attack surface** Users can take charge of their device through our hardware control feature enabling users to manage hardware components and sensors (Wi-Fi, Bluetooth, Location, USB, etc.) reducing the attack surface by switching them on and off depending on their use. **Integrity attestation** A state-of-the-art software attestation flow alerts users if there is any discrepancy between the installed software and settings of the device and their software policies. The flow utilizes a server-side fingerprint of their settings with their actual device settings. **Device wipe capability** Users can set up several device wipe triggers to delete all information on the device and render it useless. Triggers include remote wipe command, duress PIN wipe, wipe due to wrong PIN input, as well as a unique offline wipe countdown, triggering phone wipe if the device has been offline for a pre-set time period. **deGoogled** Secure OS is a completely de-Googled Android Operating System. It relies on open-source technology to deliver necessary mobile microservices such as location, push notifications, time, app updates, and others. **Secure KeyStore** All encryption keys are generated on the device and stored on a FIPS 140-2 certified cryptographic module. No private keys are ever shared or stored outside the device. Secure OS is fully integrated with [Lunar Control Center](https://docs.lunarcontrol.center). Lunar Control Center has the capability to remotely manage device configurations. # Security This section covers how Secure OS addresses techniques used by adversaries to gain access to the mobile device and its data on. An attack technique can be addressed in the following ways: * Prevention - building mechanisms that prevent the success of the technique. This is a preferred way to address the issue; * Detection - building mechanisms to detect once the technique has succeeded. This is needed in case there are no preventative mechanisms in place, or in case the preventative mechanisms fail. ### Collection attacks Collection attacks consist of techniques used to identify and gather information, such as sensitive files, from a target network prior to exfiltration. This category also covers locations on a system or network where the adversary may look for information to exfiltrate.
Keylogging **Description of attack** Adversaries may log user keystrokes to intercept credentials or other information from the user as the user types them. Mostly that’s done through masquerading as a legitimate third-party keyboard to record user keystrokes. **Prevention** * Security policy: Users can forbid the installation of any software outside of the app store managed by the MDM thus ensuring that no untrusted keyboard app gets installed. \ How to prevent: Disable *Allow installation of 3rd party apps* from [Security policies](/features/security-policies#device-policies) **Detection** * Device Integrity report: Users will be alerted if a third-party keyboard, not distributed by the organization, has been installed on the device. \ How to detect: [Device Integrity Report](/features/device-integrity-report)
Location capture **Description of attack** Adversaries may track a device’s physical location through use of standard operating system APIs via malicious or exploited applications on the compromised device. **Prevention** * Security policy: Users can disable the location services on OS API framework level, preventing any application from accessing the function.\ How to prevent: Disable *Location Access* from [Security policies](/features/security-policies#hardware-policies) * Device Integrity report: Users will be alerted if a malicious app collecting screen feed has been installed on the device.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Adversary-in-the-Middle **Description of attack** Adversaries may attempt to position themselves between two or more networked devices to support follow-on behaviors such as Transmitted Data Manipulation or Endpoint Denial of Service. Adversary-in-the-Middle can be achieved through several mechanisms. The most common is through a malicious application that registers itself as a VPN client, effectively redirecting device traffic to adversary-owned resources. A malicious application with escalation privileges can gain access to network traffic. **Prevention** * Security policy: Users can forbid the installation of any software outside of the app store managed by the MDM thus ensuring that no untrusted VPN app gets installed.\ How to prevent: Disable *Allow installation of 3rd party apps* from [Security policies](/features/security-policies#device-policies) **Detection** * Device Integrity report: Users will be alerted if a VPN app, not distributed by the organization, has been installed on the device.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Audio capture **Description of attack** Adversaries may capture audio to collect information by leveraging standard operating system APIs of a mobile device. Examples of audio information adversaries may target include user conversations, surroundings, phone calls, or other sensitive information **Prevention** * Security policy: Users can disable the use of the microphone on OS hardware abstraction level, preventing any applications from accessing it.\ How to prevent: Disable *Microphone* from [Security policies](/features/security-policies#hardware-policies) **Detection** * Device Integrity report: Users will be alerted if a malicious app collecting audio feed has been installed on the device.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Screen capture **Description of attack** Adversaries may use screen capture to collect additional information about a target device, such as applications running in the foreground, user data, credentials, or other sensitive information. Applications running in the background can capture screenshots or videos of another application running in the foreground by using the Android `MediaProjectionManager.` **Prevention** * Security policy: Users can disable the screenshot function on OS level, preventing any application from accessing the function.\ How to prevent: Disable *Screenshots* from [Security policies](/features/security-policies#hardware-policies) **Detection** * Device Integrity report: Users will be alerted if a malicious app collecting screen feed has been installed on the device.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Sensor values capture **Description of attack** Adversaries may collect a device’s sensor values (accelerometer, gravity, orientation, etc.) through use of standard operating system APIs via malicious or exploited applications on the compromised device. With the information, the adversaries can get more contextual information about the user's device. **Prevention** * Security policy: Users can disable or spoof the device sensors on OS hardware abstraction level, preventing any application from accessing the data. \ How to prevent: Disable *Sensors* from [Security policies](/features/security-policies#sensor-policies) \ :warning:Disabling sensors is not recommended due to the effect it may have on services. **Detection** * Device Integrity report: Users will be alerted if a malicious app collecting sensor values has been installed on the device.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Silent SMS **Description of attack** The adversary sends a spoofed or silent SMS to retrieve the subscriber profile identifier and thus track the device's location. Silent SMS attacks are initiated without notifying the user. **Prevention** * Security policy: Users can disable the voice and SMS services on OS framework level, preventing silent SMS and silent calls from executing.\ How to prevent: Disable *SMS/MMS* from [Security policies](/features/security-policies#device-policies)
Silent call **Description of attack** The adversary initiaties a silent Call to retrieve the subscriber profile identifier and thus track the device's location. Silent Call attacks are initiated without notifying the user. **Prevention** * Security policy: Users can disable the voice and SMS services on OS framework level, preventing silent SMS and silent calls from executing.\ How to prevent: Disable Phone/Voice services from [Security policies](/features/security-policies#device-policies)
### Initial access attacks The initial access tactic represents the vectors adversaries use to gain an initial foothold onto a mobile device.
Drive-by compromise **Description of attack** Adversaries may gain access to a device through a user visiting a website over the normal course of browsing. With this technique, the user's web browser is typically targeted for exploitation. The technique works by installing malicious software on the device used to spy on the user by recording information such as: keystrokes, screen recording, etc. **Prevention** * Security policy: Users can forbid the installation of any software outside of the app store managed by the MDM. \ How to prevent: Disable *Allow installation of 3rd party apps* from [Security policies](/features/security-policies#device-policies) **Detection** * Device Integrity report: Users can access a report comparing the application version installed on the phone and the application version permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Application versioning **Description of attack** An adversary may push an update to a previously benign application to add malicious code. This can be accomplished by pushing an initially benign, functional application to a trusted application store, such as the Google Play Store or the Apple App Store. This allows the adversary to establish a trusted user base that may grant permissions to the application before introducing malicious code. Then, an application update could be pushed to introduce malicious code. **Prevention** * Security policy: The allowed applications are updated only from the MDM, preventing any unwanted application updates. \ How to prevent: Initiated automatically by design. **Detection** * Device Integrity report: Users can access a report comparing the application version installed on the phone and the application version permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Lock screen bypass **Description of attack** An adversary with physical access to a mobile device may seek to bypass the device’s lock screen. Several methods exist to accomplish this, including: * Brute force: An adversary could attempt to brute-force the device password. * Thermal: Thermal cameras can capture the heat left by fingers on a touchscreen. The residual heat pattern can reveal the sequence of touches or the shape of a pattern. **Prevention** * Scrambled PIN: the OS introduces a scrambled PIN pad used for unlocking the device. The scrambled PIN pad ensures that patterns through Thermal images can not be identified\ How to prevent: Enable Scrambled Lockscreen Numpad from [Security policies](/features/security-policies#device-policies) * Security policy: The user is allowed for a maximum of 10 unsuccessful attempts to unlock the device. After reaching the 10th unsuccessful attempt in a row, the device will get wiped. \ How to prevent: Initiated automatically by design.
Phishing **Description of attack** Adversaries may send malicious content to users in order to gain access to their mobile devices. All forms of phishing are electronically delivered social engineering. Adversaries can conduct both non-targeted phishing, such as in mass malware spam campaigns, as well as more targeted phishing tailored for a specific individual, company, or industry, known as "spearphishing". The technique works by installing malicious software on the device used to spy on the user by recording information such as keystrokes, screen recording, etc. **Prevention** * Security policy: Users can forbid the installation of any software outside of the app store managed through the MDM. \ How to prevent: Disable *Allow installation of 3rd party apps* from [Security policies](/features/security-policies#device-policies) **Detection** * Device Integrity report: Users can access a report comparing applications installed on the phone and applications permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Replication Through Removable Media **Description of attack** Adversaries may move onto devices by exploiting or copying malware to devices connected via USB. In the case of Lateral Movement, adversaries may utilize the physical connection of a device to a compromised or malicious charging station or PC to bypass application store requirements and install malicious applications directly. **Prevention** * Locked bootloader: Secure OS-powered devices are with locked bootloaders, preventing arbitrary operating system code from being flashed onto the device.\ How to prevent: Initiated automatically by design. * Security policy: users can restrict the file transfer functionality of the USB port, thus preventing the ability of adversaries from transferring malicious software to the device.\ How to prevent: Disable *USB* from [Security policies](/features/security-policies#hardware-policies) * Remote device wipe: Users can remotely wipe the device, either by initiating a device wipe command (available when the device is online) or by setting an automated wipe flow triggering when the device has been offline for a period selected by the user.\ How to wipe: [Device wipe](/features/device-wipe)
Impersonalization attack **Description of attack** Adversaries may use the victim's credentials to log into their user account from another device. Through that adversaries obtain information backed by the user in the cloud. **Prevention** * Device backup encryption: The optional device backup is fully encrypted, requiring the user to enter a backup password requiring the adversary with an enrolled user account to guess the backup password as well. * Security policy: users can forbid account re-enrollment, preventing anyone else from enrolling their account on a new device or on the same device after the device wipe, technically making the account completely inaccessible. \ How to prevent: Disable Re-enrollment from [Security policies](/features/security-policies#account-policies)
### Execution attacks Execution consists of techniques that result in adversary-controlled code running on a mobile device. Techniques that run malicious code are often paired with techniques from all other tactics to achieve broader goals, like exploring a network or stealing data.
Command scripting **Description of attack** Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries. These interfaces and languages provide ways of interacting with computer systems and are a common feature across many different platforms. Most systems come with some built-in command-line interface and scripting capabilities, for example, Android is a UNIX-like OS and includes a basic Unix Shell that can be accessed via the Android Debug Bridge (ADB) or Java’s Runtime package. **Prevention** * Hardware-based attestation: Secure OS utilizes a hardware-based device attestation designed to prevent the device from starting in case it has been rooted or jailbroken.\ How to prevent: Initiated automatically by design.
Exploitation of client execution **Description of attack** Adversaries may exploit software vulnerabilities in client applications to execute code. Vulnerabilities can exist in software due to insecure coding practices that can lead to unanticipated behavior. Adversaries may take advantage of certain vulnerabilities through targeted exploitation for the purpose of arbitrary code execution. Oftentimes the most targeted applications are system applications since they come preinstalled with full device access. **Mitigation** * System apps: Secure OS contains a very limited amount of system applications (8-12 depending on policies), in comparison to Samsung and iPhone devices with over 50 preinstalled apps. \ How to prevent: Initiated automatically by design.
### Persistence attacks Persistence is any access, action, or configuration change to a mobile device that gives an attacker a persistent presence on the device. Attackers often will need to maintain access to mobile devices through interruptions such as device reboots and potentially even factory data resets.
Boot or Logon Initialization Scripts **Description of attack** Adversaries may use scripts automatically executed at boot or logon initialization to establish persistence. Initialization scripts are part of the underlying operating system and are not accessible to the user unless the device has been rooted or jailbroken. **Prevention** * Hardware-based attestation: Secure OS utilizes a hardware-based device attestation designed to prevent the device from starting in case it has been rooted or jailbroken.\ How to prevent: Initiated automatically by design. * Locked bootloader: Secure OS-powered devices are with locked bootloaders, preventing arbitrary operating system code from being flashed onto the device.\ How to prevent: Initiated automatically by design. **Detection** * Device Integrity report: Users can access a report comparing device settings and settings permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Compromise Client Software Binary **Description of attack** Adversaries may modify system software binaries to establish persistent access to devices. System software binaries are used by the underlying operating system and users over adb or terminal emulators. Adversaries may make modifications to client software binaries to carry out malicious tasks when those binaries are executed. For example, malware may come with a pre-compiled malicious binary intended to overwrite the genuine one on the device. Since these binaries may be routinely executed by the system or user, the adversary can leverage this for persistent access to the device. **Prevention** * Hardware-based attestation: Secure OS utilizes a hardware-based device attestation designed to prevent the device from starting in case it has been rooted or jailbroken.\ How to prevent: Initiated automatically by design. * Locked bootloader: Secure OS-powered devices are with locked bootloaders, preventing arbitrary operating system code from being flashed onto the device.\ How to prevent: Initiated automatically by design. **Detection** * Device Integrity report: Users can access a report comparing device settings and settings permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Event Triggered Execution **Description of attack** Adversaries may establish persistence using system mechanisms that trigger execution based on specific events. Mobile operating systems have means to subscribe to events such as receiving an SMS message. Adversaries may abuse these mechanisms as a means of maintaining persistent access to a victim via automatically and repeatedly executing malicious code. After gaining access to a victim’s system, adversaries may create or modify event triggers to point to malicious content that will be executed whenever the event trigger is invoked. **Prevention** * Security policy: users can limit the device attack surface by disabling device services, including SMS, Voice calls, etc.\ How to prevent: disable SMS/MMS and Voice services from [Security policies](/features/security-policies#device-policies) **Detection** * Device Integrity report: Users can access a report comparing device settings and settings permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Foreground persistence **Description of attack** Adversaries may abuse Android's startForeground() API method to maintain continuous sensor access, including camera, microphone, gyroscope, etc.. Applications can retain sensor access by running in the foreground, using Android’s startForeground() API method. **Prevention** * Security policy: users can limit the device attack surface by disabling device sensors, including WiFi, Bluetooth, Locations, USB, fingerprint, accelerometer, gyroscope, etc.\ How to prevent: Disable unused *Hardware* and *Sensors* from [Security policies](/features/security-policies#hardware-policies) and [Security policies](/features/security-policies#sensor-policies) **Detection** * Device Integrity report: Users can access a report comparing device settings and settings permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
### Privilege escalation attacks Privilege escalation includes techniques that allow an attacker to obtain a higher level of permissions on the mobile device. Attackers may enter the mobile device with very limited privileges and may be required to take advantage of a device weakness to obtain higher privileges necessary to successfully carry out their mission objectives.
Exploitation for Privilege Escalation **Description of attack** Adversaries may exploit software vulnerabilities in order to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in an application, service, within the operating system software, or kernel itself to execute adversary-controlled code. Security constructions, such as permission levels, will often hinder access to information and the use of certain techniques. Adversaries will likely need to perform privilege escalation to include the use of software exploitation to circumvent those restrictions. **Prevention** * Hardware-based attestation: Secure OS utilizes a hardware-based device attestation designed to prevent the device from starting in case it has been rooted or jailbroken.\ How to prevent: Initiated automatically by design. **Detection** * Device Integrity report: Users can access a report comparing device settings and settings permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
### Defense evasion attacks Defense evasion consists of techniques an adversary may use to evade detection or avoid other defenses. Sometimes these actions are the same as or variations of techniques in other categories that have the added benefit of subverting a particular defense or mitigation. Defense evasion may be considered a set of attributes the adversary applies to all other phases of the operation.
Hooking **Description of attack** Adversaries may utilize hooking to hide the presence of artifacts associated with their behaviors to evade detection. Hooking can be used to modify return values or data structures of system APIs and function calls. This process typically involves using 3rd party root frameworks, with either a system exploit or pre-existing root access. **Prevention** * Hardware-based attestation: Secure OS utilizes a hardware-based device attestation designed to prevent the device from starting in case it has been rooted or jailbroken.\ How to prevent: Native OS feature.\ How to prevent: Initiated automatically by design. * Locked bootloader: Secure OS powered devices are with locked bootloaders, preventing arbitrary operating system code from being flashed onto the device.\ How to prevent: Initiated automatically by design.
Impair Defenses **Description of attack** Adversaries may maliciously modify components of a victim's environment in order to hinder or disable defensive mechanisms. This not only involves impairing preventative defenses, such as anti-virus, but also detection capabilities that defenders can use to audit activity and identify malicious behavior. This may span both native defenses as well as supplemental capabilities installed by users or mobile endpoint administrators. **Prevention** * Boot integrity check: Secure OS initiates a boot integrity check that verifies that no unauthorized modification of system files has been done. The device does not start if the boot integrity check doesn't pass. \ How to prevent: Initiated automatically by design.
Obfuscated Files or Information **Description of attack** Adversaries may attempt to make a payload or file difficult to discover or analyze by encrypting, encoding, or otherwise obfuscating its contents on the device or in transit. This is common behavior that can be used across different platforms and the network to evade defenses. Payloads may be compressed, archived, or encrypted in order to avoid detection. These payloads may be used during Initial Access or later to mitigate detection. Portions of files can also be encoded to hide the plaintext strings that would otherwise help defenders with discovery. Payloads may also be split into separate, seemingly benign files that only reveal malicious functionality when reassembled. **Prevention** * Security policy: Users can forbid the installation of any software outside of the app store managed by the MDM thus ensuring that no untrusted apps get installed.\ How to prevent: Disable *Allow installation of 3rd party apps* from [Security policies](/features/security-policies#device-policies) **Detection** * Device Integrity report: Users can access a report comparing the application version installed on the phone and the application version permitted by the MDM. Discrepancies are triggering alerts for administrators and users.\ How to detect: [Device Integrity Report](/features/device-integrity-report)
Code Signing Policy Modification **Description of attack** Adversaries may modify code signing policies to enable the execution of applications signed with unofficial or unknown keys. Code signing provides a level of authenticity on an app from a developer, guaranteeing that the program has not been tampered with and comes from an official source. Security controls can include enforcement mechanisms to ensure that only valid, signed code can be run on a device. **Prevention** * Security policy: Users can forbid the installation of any software outside of the app store managed by the MDM thus ensuring that no untrusted apps get installed. All applications distributed through the MDM require a trusted certificate prior to whitelisting the app.\ How to prevent: Disable *Allow installation of 3rd party apps* from [Security policies](/features/security-policies#device-policies) **Detection** * Certificates report: Users can use the device settings menu to view trusted CA certificates and look for unexpected or unknown certificates.\ How to detect: Settings > Security > Encryption & credentials > Trusted credentials
# Features # Security policies ### About the feature One of the core features of Secure OS is the capability to manage device policies, allowing users to configure the device to address their cyber threat profile. Security Policies allow users to enable and/or disable device sensors, services, and different functions based on their preferences. ### How to access the feature Device users can interact and set up their security policies via the Phone Manager system application. Only users with a "Power user" account level can manage their own security policies through the device. {% hint style="info" %} The Security Policies can be accessed in one of the following ways: 1. Upon initial enrollment: the user is prompted to set up their security policies upon initial enrollment. Users can decide to skip it and set up their policies later 2. Accessed via: Settings > My Account > Phone Manager 3. Accessed via: Phone Manager widget on the home screen (available for some device models) {% endhint %} Below is the list of Security Policies users can manage. ### Hardware Policies Includes settings related to the availability of functions delivered by hardware components. When disabled, applications will not be able to provide functions that require the use of these components even if applications are granted access to these components. {% hint style="success" %} How to access: Phone Manager > Manage Hardware {% endhint %}
Camera Allows users to disable device cameras. Users can disable both rear and front cameras or disable only front or rear cameras.
Location access Allows users to disable access to location services by the device. #### Extension: As an extension to the function, a spoof location can be set which will use a predefined and fixed location value instead of the real device location.
USB Allows users to disable USB functions including File Transfer, MIDI, PTP for connected devices. Disabling the USB will not prevent the device from charging through it.
Bluetooth Allows users to disable Bluetooth connection on the device.
WiFi Allows users to disable WiFi connectivity functions on the device.
Screenshots Allows users to disable screenshot taking on the device. The screenshot-taking permissions affect screenshot-taking through any application, including system or third-party applications.
Microphone Allows users to disable the usage of the microphone on the device. Disabling the microphone will prevent all voice functionality including calls, push-to-talk messages, audio recording, and audio feed on recorded videos.
Fingerprint Allows users to disable the usage of the fingerprint sensor on the device.
Developer options Allows users to disable the Developer options on the device.
### Device Policies Includes settings related to the availability of different device functions. When disabled the functions will not be accessible by any application. {% hint style="success" %} How to access: Phone Manager > Manage Device {% endhint %}
Phone/Voice services Allows users to disable voice services on the device. When disabled it restricts all incoming and outgoing telephony calls on the device. VoIP calls made through apps (such as Secure Chat) are not restricted.
SMS/MMS Allows users to disable SMS and MMS services on the device. When disabled it restricts all incoming and outgoing SMS or MMS messages, including silent SMS or MMS. Chat messages made through apps (such as Secure Chat) are not restricted.
Micro G Services Allows users to disable Micro G services on the device. When disabled, the following services will be affected: * Location services will not be provided * Push notifications will not be provided for third-party apps that do not have a dedicated notification delivery service.
Manage Screen timeout Allows users to disable the capability to change the screen timeout on the device. Devices with disabled screen timeout will use the default screen timeout.
Scrambled Lockscreen Numpad Allows users to enable a scrambled lock screen numpad feature. The scrambled numpad is affecting the device lock screen.
Sync interval / Max failed sync Allows users to change the frequency of the sync between device and server. The Sync interval in combination with Max failed sync determines the threshold set by the user for the maximum allowed time for the device to be "offline". When the threshold is reached, an automated device wipe flow will trigger and delete all of the device data. For example, if the Sync interval is 4 hours, and the Max Failed Sync is set to 50, the device will wipe if it fails to sync 50 times in a row, with an attempt to sync every 4 hours (wiping the phone if it is offline for 200 hours).
Can download updates on Mobile Data Allows users to disable OS updates downloading via Mobile Data, requiring a WiFi connection to download the OS update.
Allow installation of 3rd party apps Allows users to disable installation of any software outside of the System App Store. When disabled, no software can be installed through any third-party App Store or a local install (e.g. APK file).
Allow apps full device access Allows users to restrict third-party applications from getting device access. Enabling this will not automatically grant access to third-party applications. To do that, users should enable this policy and also grant each app the accesses they need, from Settings > Privacy > Permission Manager or from Settings > Apps & notifications > (select app) > Permissions
### Account Policies Includes settings related to the user account on devices. {% hint style="success" %} How to access: Phone Manager > Manage Account {% endhint %}
Re-enrollment Users can disable account re-enrollment, which will prevent enrollment with the same account on the same or another device.
Enable WIPE password Allows users to set a WIPE PIN used for instant device wipe when the selected PIN is entered on device unlock.
Update account password Allows users to restrict the change of their user account password.
### Sensor Policies Includes settings related to the availability and functionality of the device sensors. {% hint style="success" %} How to access: Phone Manager > Manage Sensor {% endhint %}
Accelerometer Allows users to disable the accelerometer sensor used to measure the acceleration force in m/s2 that is applied to a device on all three physical axes (x, y, and z), including the force of gravity. #### Extension: As an extension to the function, the user can spoof the values of the sensor.
Geomagnetic field Allows users to disable the geomagnetic field sensor used to measure the ambient geomagnetic field for all three physical axes (x, y, z) in μT. #### Extension: As an extension to the function, the user can spoof the values of the sensor.
Gravity Allows users to disable the gravity sensor used to measure the force of gravity in m/s2 that is applied to a device on all three physical axes (x, y, z). #### Extension: As an extension to the function, the user can spoof the values of the sensor.
Gyroscope Allows users to disable the gyroscope sensor used to measure a device's rate of rotation in rad/s around each of the three physical axes (x, y, and z). #### Extension: As an extension to the function, the user can spoof the values of the sensor.
Light Allows users to disable the light sensor used to measure the ambient light level (illumination) in lx. #### Extension: As an extension to the function, the user can spoof the values of the sensor.
Linear acceleration Allows users to disable the linear acceleration sensor used to measure the acceleration force in m/s2 that is applied to a device on all three physical axes (x, y, and z), excluding the force of gravity. #### Extension: As an extension to the function, the user can spoof the values of the sensor.
Orientation Allows users to disable the orientation sensor used to measure degrees of rotation that a device makes around all three physical axes (x, y, z). #### Extension: As an extension to the function, the user can spoof the values of the sensor.
Proximity Allows users to disable the proximity sensor used to measure the proximity of an object relative to the view screen of a device. This sensor is typically used to determine whether a handset is being held up to a person's ear. #### Extension: As an extension to the function, the user can spoof the values of the sensor.
Rotation vector Allows users to disable the rotation vector sensor used to measure the orientation of a device by providing the three elements of the device's rotation vector. #### Extension: As an extension to the function, the user can spoof the values of the sensor.
# Device wipe Device Wipe is the process of deleting all device data and logging out of the user account. The device Wipe is useful when the user has lost access to their device, or if the user is offboarded from the organization. Secure OS supports the following Wipe flows: ### Automated Wipe Devices are getting automatically wiped if the user fails to enter the right screenlock PIN/password for 10 consecutive times in a row. ### Duress Wipe The user can use a duress wipe action that triggers a device wipe if they enter a predefined PIN (Wipe PIN) in the lock screen menu. The user can set up their Duress Wipe from their Account Policy in Phone Manager (how to: [Security policies](/features/security-policies#enable-wipe-password)) ### Remote Wipe The device can be remotely wiped by the MDM administrator through an instant Wipe command. The device will be wiped as long as has connectivity. ### Failed Sync Wipe Users can set up a Failed Sync Wipe flow that will trigger a device Wipe in case the device fails to sync to the server for "n" number of times (also meaning that the device is offline). This feature ensures that the device will get wiped even if it loses connectivity and is unable to receive a remote wipe command from the MDM. (how to: [Security policies](/features/security-policies#sync-interval-max-failed-sync)) ### Emergency Wipe The user can also initiate a device wipe from their Emergency menu in Secure OS. (how to: Hold power button > Emergency > SOS and data reset {% hint style="info" %} The combination of device wipe and Re-enrollment disabled by policy (how to: [Security policies](/features/security-policies#re-enrollment)) renders the account no longer accessible, regardless of whether the user enters the right username and password. {% endhint %} # Device Integrity Report ### About the feature The Device Integrity report is the main feature of Secure OS for detection of malicious activity on the device. The Device Integrity checks the following: {% hint style="success" %} How to access: 1. Settings > My Account > Phone Manager > Device Integrity 2\. When in home screen menu: Swipe down (to open the settings bar) > Swipe down again (to open the notification bar) > Press the shield icon on the bottom right corner {% endhint %} ### Software integrity The local device policies and installed software (apps and OS) are compared to the policies saved on the server. Any discrepancies are reported with the user being alerted. The user can access detailed logs in case there is a discrepancy, to understand where the discrepancy is coming from. ### Hardware integrity Secure OS utilizes a hardware-based device attestation designed to prevent the device from starting in case it has been rooted or jailbroken. The user can access a report of the components checked. # Boot integrity check To ensure that the device is running on an authentic version of Secure OS and that no system applications have been manipulated, the device performs a custom partition validation, starting from the hardware-protected root of trust, continuing with the bootloader, the boot partition, and other partitions such as the system, vendor, and OEM. Each stage verifies the integrity of the next, by calculating and comparing the current hash value of each partition with the expected one. If at any point in the verification, the expected hash value doesn’t match the calculated one, the boot-up process will be terminated and the user will not be able to access the device. {% hint style="info" %} The Boot Integrity Check process is initiated every time the device is booted (after turning it on or restarting it). {% endhint %} # Device backup Secure OS supports a device backup and restore functionality through the Backup Manager app. {% hint style="success" %} The Backup Manager app can be accessed through Settings > System > Backup {% endhint %} The backup includes:
App data Includes app data only. The user needs to download apps again prior to restoring app data.
Files Includes all of the documents, photos, and other media stored in the internal device storage
Systems settings Includes systems settings such as wi-fi networks, display preferences, sound settings, language choices, and more.
# Password management Users are able to change the following passwords: ### Change account password The Account password is used to enroll the device with the user account. The user can change the account password from the device once enrolled through Settings > Security > Account password The new password should fit the minimum password quality requirements defined in the MDM. ### Change lock screen The Lock Screen is used to unlock the device and the phone manager app. The user can change the lock screen from the device once enrolled through Settings > Security > Lock screen protection. The new password should fit the minimum password quality requirements defined in the MDM.