« View all posts

Unmanaged, privacy-first security policies now available

Posted by James Donaldson on November 27, 2023

Table of Contents

Device Management in modern times

Unmanaged Policy vs Managed MDM

  1. Typical MDM protocols
  2. Unmanaged policy differences

Why use lockdown policy on a "Secure" OS?

What can I lockdown with my CopperheadOS device?

Use-cases for privacy-first security policies

  1. Legal firms
  2. IT staff

Copperhead exclusive security policies

  1. Disabling front camera
  2. Disabling back camera

Thwarting USB Forensics and Attacks

  1. Default USB-allowed access
  2. USB data disabled

Device Management in modern times

Managing mobile devices has been a common security practice for decades. Device security ensures that the data on the device is secured and with the addition of a device management policy, organizations can enact specific compliance strategies based on their use-cases. Ensuring asset retention if a device is lost, stolen or compromised is of the utmost importance to IT departments protecting the organization from IP theft or worse.

CopperheadOS currently supports all major MDM vendors.

Device management adds an important customizable layer of mobility security for any device.

Unmanaged Policy vs Managed MDM

MDM policy process

MDM architecture

MDMs utilize a push-and-pull client/server process to retrieve device information and apply their MDM policies on device. If an MDM device is recognized as uncompliant, the MDM will then enact it's security process -- either wiping the device, locking it out or forcefully adding the policy on a device. This provides MDM servers with information about the device, as well as data on the device by design. Information on the device is retrievable, logged and stored for use by the organization or MDM vendor for various reasons. This in itself isn't bad -- but it certainly isn't privacy-first. What's worse, MDM breaches have occurred where device information was logged in breaches or where the MDM was used as a tool to push out a malicious update to the entire fleet. MDM's are juicy targets for attackers as they provide a centralized-administration point over the entire organization's fleet of devices.

Unmanaged privacy-first Copperhead policy

Server-less architecture

Copperhead's policy is pull-only which ensures that devices will not burn their data looking for updates and no data can be retrieved from the device. The only thing requested from Copperhead servers is the Policy version of the client -- which enables Copperhead to determine if the device's policy is updated correctly or not. If the Policy version we have is updated, CopperheadOS devices will pull down the version and update accordingly.

Security baked in

Copperhead's policy works without a client-controlling server, meaning there is no juicy MDM SPOF to target by attackers. Protected by our redundantly secured and air-gapped security signing keys process which ensures malicious policies cannot be injected or pushed inadvertently. Unlike typical MDM deployments, Copperhead's Policy is baked in as a system app which means it cannot be disabled, frozen or tampered with on the device, ensuring full verification of the device integrity.

No other device data or personal data is retrieved in any part of the policy process.


I run a Secure OS already. Why should I manage my device?

CopperheadOS has always lead the way in security, privacy and innovation in the Android space. Since Copperhead started in 2014, many other projects and products have emerged in the market. Many purport to be secure and private while being unable to explain in basic language why they are secure.

Copperhead's security policy enables a strict device management policy while limiting the attack surface and protecting the privacy of the user and Partner. Lockdown ensures that a device will act in accordance to it's function even under threat or execution of breach. No other secure OS vendor on the market has this capability.

There are many reason to run a locked down device. Some include:

  • Ensuring devices follow strict compliance (ie: CMMC, ISO27001, FIPS, HIIPA)
  • Restricting the avenues of attack away from user error
  • Enabling a single-purpose device to retain communication integrity

What can I lockdown with my CopperheadOS device?

Nearly everything on the device is possible to modify. Some of the more popular lockdown policies from our Partners are:

  • No 3rd party appstore (Google, F-Droid, etc)
  • Only 1st party appstore with specific Applications
  • No browser, contacts, dialer
  • Cameras disabled
  • Location, WiFi, Bluetooth (media available, no scanning) disabled
  • USB/ADB disabled

Use-cases for privacy-first security policies

legal firm

One of the most important things to validate a legal case for attorneys is to ensure that their client's confidentiality is assured. While legally backed, being able to technically ensure that the communication's between them and their client are free of surveillance. Devices should be restricted to only specific apps without access to browsers, dialers, external contacts and limit the possibility of remote or local compromise.

IT production staff (DevOps, Cybersecurity teams)

datacenter

IT staff are the foundation for any technology company. They keep the servers running and secure, while defending attackers and ensuring the rest of the technical staff are working according to their compliance requirements. Not just as of late, but occurring more often, IT staff are a juicy target for attackers as they often hold the "keys to production." The keys are generally remote access keys in the form of SSH, rsync, RDP, or other RMM protocols, that ensure that they can reach their servers for maintenance or in case of an emergency. If these keys are compromised, the entire security paradigm of the organization is thrown out. Ensuring IT staff's mobility solution is secure from the ground up is essential.

IT production staff example lockdown

  • Specific application use
  • Limited appstore with apps only approved by CISO or above management
  • Removal of privacy-invasive components - NFC
  • Whitelisted WiFi AP list and/or specific SIM/APN whitelist
  • Enforced application and OS updates

Copperhead-exclusive policy options

Disabling back and/or front camera

The security policy can disable the front camera, back or both cameras so that even in the unlikely event of the device being exploited the camera will still not show the user or be able to take pictures.

Front camera disabled

datacenter

Back camera disabled

datacenter

Thwarting USB forensics and attacks

USB attacks have been the defacto forensic standard of retrieving data from a mobile device for years. The state of Android USB security has been abysmal and continues to provide an easy avenue for forensic-analysis tools to breach devices. Off-the-shelf tools make retrieving data from a device incredibly simple and will often come packaged with device exploits that ensure complete device access.. While Android has made leaps in bounds in recent years by ensuring that ADB has to be authorized physically, this still does not protect a device if it's been retrieved while unlocked or if ADB is enabled. This includes all current secure OS's on the market.

Copperhead's security policy can lock down USB data and completely remove ADB so that, even under physical device compromise, no information can be retrieved from the device while still enabling power charging from the port!

Default USB-allowed access

Here we can use Powershell to determine all USB devices connected to the computer/forensic device:

Get-WmiObject Win32_USBControllerDevice | Foreach-Object { $_; [Wmi]$_.Dependent }

This command enables a user to retrieve all devices connected via USB and filter by Android devices. Feel free to try it out on your own computer with an Android device connected!

Get-WmiObject Win32_USBControllerDevice | Foreach-Object { $_; [Wmi]$_.Dependent } | Where-Object {$_.Description -match 'Android*' }

Below is a snippit from a Windows computer demonstrating an Android device connected via USB. Here you can see the entirety of the USB-connected device's details and is only one step away from full device access.

PS C:\> Get-WmiObject Win32_USBControllerDevice | Foreach-Object { $_; [Wmi]$_.Dependent } | Where-Object {$_.Description -match 'Android*' }

__GENUS                     : 2
__CLASS                     : Win32_PnPEntity
__SUPERCLASS                : CIM_LogicalDevice
__DYNASTY                   : CIM_ManagedSystemElement
__RELPATH                   : Win32_PnPEntity.DeviceID="USB\\VID_18D1&PID_4EE7\\16171JECB12277"
__PROPERTY_COUNT            : 26
__DERIVATION                : {CIM_LogicalDevice, CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER                    : WIN-COPPERHEAD
__NAMESPACE                 : root\cimv2
__PATH                      : \\WIN-COPPERHEAD\root\cimv2:Win32_PnPEntity.DeviceID="USB\\VID_18D1&PID_4EE7\\16171JECB12277"
Availability                :
Caption                     : Android Composite ADB Interface
ClassGuid                   : {3f966bd9-fa04-4ec5-991c-d326973b2b0e}
CompatibleID                : {USB\MS_COMP_WINUSB, USB\COMPAT_VID_18D1&Class_FF&SubClass_42&Prot_01, USB\COMPAT_VID_18D1&Class_FF&SubClass_42, USB\COMPAT_VID_18D1&Class_FF…}
ConfigManagerErrorCode      : 0
ConfigManagerUserConfig     : False
CreationClassName           : Win32_PnPEntity
Description                 : Android Composite ADB Interface
DeviceID                    : USB\VID_18D1&PID_4EE7\16171JECB12277
ErrorCleared                :
ErrorDescription            :
HardwareID                  : {USB\VID_18D1&PID_4EE7&REV_0440, USB\VID_18D1&PID_4EE7}
InstallDate                 :
LastErrorCode               :
Manufacturer                : LeMobile
Name                        : Android Composite ADB Interface
PNPClass                    : AndroidUsbDeviceClass
PNPDeviceID                 : USB\VID_18D1&PID_4EE7\16171JECB12277
PowerManagementCapabilities :
PowerManagementSupported    :
Present                     : True
Service                     : WinUSB
Status                      : OK
StatusInfo                  :
SystemCreationClassName     : Win32_ComputerSystem
SystemName                  : WIN-COPPERHEAD
PSComputerName              : WIN-COPPERHEAD

USB data disabled

Using the exact same Powershell commands on a locked down CopperheadOS device shows that the USB bus is completely disabled from providing any information, blocking any retreiving of data.

PS C:\> Get-WmiObject Win32_USBControllerDevice | Foreach-Object { $_; [Wmi]$_.Dependent } | Where-Object {$_.Description -match 'Android*' }

PS C:\>

Used in conjunction with our ADB-removed policy will completely stop USB forensic attacks from devices that are retrieved -- even when unlocked and while still allowing power charging from the USB port.


Reach out to us to get your CopperheadOS journey started..

We offer full rebrand, locked down and secure device customizable packages to any assortment of industries.