How DeviceTone Mitigates the OWASP Top 10 Threats for IoT

14

July 2020

by Moshe Ferber

The OWASP top 10 threats to IoT started as an OWASP project with a goal of helping developers, manufacturers, enterprises, and consumers to make better decisions regarding the creation and use of IoT systems.

When building DeviceTone, we gave a considerable amount of attention not only to avoid mistakes that can compromise our devices but also building an infrastructure that will mitigate the top threats of IoT devices and help others in creating better, protected IoT services.

Below you will find the list of top threats and how DeviceTone mitigates those threats.

OWASP IoT Top 10 Description How DeviceTone mitigates the threat
Weak, Guessable, or Hardcoded Passwords Use of easily brute-forced, publicly available, or unchangeable credentials, including backdoors in firmware or client software that grants unauthorized access to deployed systems.

·  DeviceTone generates a unique, device-only, access key

·  This device-level secret is kept in a secure location inside the device

·  There are no default credentials used anywhere

·  Customers can always change the access credentials

 

Insecure Network Services Unneeded or insecure network services running on the device itself, especially those exposed to the internet, that compromise the confidentiality, integrity/authenticity, or availability of information or allow unauthorized remote control.

·  DeviceTone devices are hardened by default according to industry best practices

·  DeviceTone management software enables visibility and enforcement on every network service on the device

·  DeviceTone management provide secure updates in order to make sure you are always running the most updated software

Insecure Ecosystem Interfaces Insecure web, backend API, cloud, or mobile interfaces in the ecosystem outside of the device that allows compromise of the device or its related components. Common issues include a lack of authentication/authorization, lacking or weak encryption, and a lack of input and output filtering.

·  DeviceTone backend applications are built on the latest protocols, services, and standards

·  DeviceTone backend has been reviewed by security experts

·  Devicetone services were built with privacy & security by design

·  All the traffic of DeviceTone services is encrypted

·  Every API interface is authenticated with security keys that rotate periodically

·  DeviceTone application secrets are kept in a secure location

·  All human access is protected by Multi-factor authentication

 

Lack of Secure Update Mechanism Lack of ability to securely update the device. This includes lack of firmware validation on a device, lack of secure delivery (un-encrypted in transit), lack of anti-rollback mechanisms, and lack of notifications of security changes due to updates.

·  DeviceTone was built in order to supports over-the-air, secure and encrypted software updates by

·  DeviceTone only download signed firmware and only on an encrypted channel

·  DeviceTone validates the signed firmware authenticity before installment

·  DeviceTone enables entire lifecycle of rolling and rollback of security updates

Use of Insecure or Outdated Components Use of deprecated or insecure software components/libraries that could allow the device to be compromised. This includes insecure customization of operating system platforms and the use of third-party software or hardware components from a compromised supply chain

·  DeviceTone backend servers are patched periodically

·  The over-the-air updates enable updates to devices as needed

·  DeviceTone management guarantee that when a new device is installed, it got the latest patching

·  DeviceTone management guarantee that every software update can be sent easily and securely

Insufficient Privacy Protection User’s personal information stored on the device or in the ecosystem that is used insecurely, improperly, or without permission.

·  For most projects, DeviceTone is not keeping data on the device

·  Once data moved to the cloud all the information is located in a secure location

·  Access permissions are based on the least-privilege principle

·  There is a separation of duties between device administrators and private data administrators

·  DeviceTone can make sure that data from different jurisdictions are kept at the relevant locations (in order to follow GDPR guidelines, i.e.)

 

 Insecure Data Transfer and Storage Lack of encryption or access control of sensitive data anywhere within the ecosystem, including at rest, in transit, or during processing

·  All traffic from DeviceTone to backend servers or between backend servers is encrypted by default

·  Traffic encryption between DeviceTone gateway and IoT sensors is dependent on protocol used

·  Information store on backend servers is secured and encrypted by cloud provider service

·  Access to encryption keys is limited and based on the least principle privilege

Lack of Device Management Lack of security support on devices deployed in production, including asset management, update management, secure decommissioning, systems monitoring, and response capabilities. ·  DeviceTone is a powerful management tool that can handle all deployment life cycle of the devices including provisioning and de-provisioning, secure update procedures, monitoring, patches and more
Insecure Default Settings Devices or systems shipped with insecure default settings or lack the ability to make the system more secure by restricting operators from modifying configurations.

·  DeviceTone provisioned with a unique password/secret per device

·  Any security configuration on the devices is modifiable by operators

·  DeviceTone devices are hardened by default

Lack of Physical Hardening Lack of physical hardening measures, allowing potential attackers to gain sensitive information that can help in a future remote attack or take local control of the device.

·  All DeviceTone secrets are kept in a secure location where only the device IOT service can reach

·  All traffic is timestamped in order to prevent reply attacks

·  If the internal storage is compromised, the attacker can only gain access to specific device data

 

Similar Blogs