Embedded device security - A security feature gap analysis applying a threat modeling methodology. A guide for users of embedded devices.

Threat Modeling Embedded Devices - A Security Feature Gap Analysis

Introduction

Embedded devices provide a means of facilitating processes and workloads on a micro scale. They harness the use of multiple peripherals at minimal power consumption. These devices could be embedded into hospital analytical equipment, medical devices, autonomous vehicles or embedded into operation technology to control processes on an industrial scale via an edge network. In general, embedded devices are connected to various services for further processing/storage of data or update services to remotely process software or firmware updates. Often these devices do not contain on-chip memory for data storage; data is stored on a local removable memory card and therefore data processing may be limited or vulnerable to attack via local physical techniques.

During an embedded device’s service; peripheral, data in-transit/data at-rest, memory and storage processes are executed on a continuous on-demand basis. With the multitude of services and processes running on the devices, here enters the possibility for insecure code or system weaknesses, thus security features and secure coding practices must be taken into serious consideration. Adhering to industry best practices regarding embedded device security will provide the device with a higher level of integrated resilience to any form of malicious activities directed at the device or its associated service infrastructure.

This article will analyse an embedded device’s vital features and components against the specified available security features. A gap analysis of the security feature to expected weaknesses will provide a means of discovering any embedded device security related issues. Security control recommendations will be derived and subsequently detailed from the gap analysis results.

Security Gap Analysis Process & Methodology

Gather relevant information on the embedded device main features, peripherals, communications mediums, libraries, software etc..
Identify and compile a list of the embedded device security features that are available.
Identify and prepare a list of corresponding Common Weakness Enumeration (CWE) types crucial to the Embedded Device specification and features. (These will vary depending on features, peripherals and software available).
Evaluate the present security features against the selected CWE’s. The evaluation process will support detection of any security gaps.
Provide additional recommendations for vulnerable embedded device features. (Refer to last two columns in Table 1 for IEC/ANSI 62443 4-2 control recommendations).

1. Embedded Device Functional Features and Components:

Feature details extracted from the device’s specification and operation manual.

CPU
Memory
Clocks and timers
Wifi
Bluetooth
Multiple sensors and peripherals * Analog to Digital Converter, Digital to Analog Converter, General Purpose input/output (GPIO), HALL Sensor, Touch, Ethernet MAC interface
Flash Drive

2. Current Security Features available:

Feature details extracted from the device's specification and operation manual.

Secure boot
Flash encryption
1024-bit One-Time Programmable (OTP)
Cryptographic hardware acceleration

Advanced Encryption Standard (AES)
Hash (SHA-2)
Rivest-Shamir-Adleman (RSA)
Elliptic-curve cryptography (ECC)
Random Number Generator (RNG)

3. Anticipated Common Embedded Device Weaknesses (non-exhaustive list):

CWE-94 - Improper Control of Generation of Code ('Code Injection')

CWE-494 - Download of Code Without Integrity Check

CWE-1191 - Exposed Chip Debug and Test Interface With Insufficient or Missing Authorization

CWE-1274 - Improper Access Control for Volatile Memory Containing Boot Code

CWE-1263 - Improper Physical Access Control

CWE-1326 - Missing Immutable Root of Trust in Hardware

4. Table 1: CWE to industry standard 62443 4-2 Embedded Device Requirement (EDR) controls correlation:

Embedded Device Weaknesses	Existing Device Mitigating Security Features	Evaluation of Mitigating Control	IEC/ANSI 62443 4-2 EDR Applicable Controls	Additional Control Recommendations
CWE-94	N/A	No initial security features detected.	EDR 2.4: Use Control – Mobile Code	Run code as per a jail environment, Input validation and Environment hardening.
CWE-494	HASH (SHA-2) is available, unsure if used to check the integrity of software updates.	How are the software updates integrity checked? Updates are installed via flash. Thus the updates are downloaded via a different device and then transferred. How is the device verifying this update is legitimate? These are typical questions that would be answered while threat modeling in the embedded device’s design phase.	EDR 3.10: System Integrity – Support for Updates	Code signing. Perform reverse DNS lookups. Integrity checking. Run code using lowest privileges to perform functions.
CWE-1191	JTAG debugging interface is available but may not be restricted - possibly an open attack vector.	No apparent control for this mitigation. This interface should have restricted access.	EDR 2.13: Use Control – Use of Physical Diagnostics to Test Devices	If feasible, the manufacturer should disable the JTAG interface or implement authentication and authorization for the JTAG interface. If authentication logic is added, it should be resistant to timing attacks. Security-sensitive data stored in registers, such as keys, etc. should be cleared when entering debug mode.
CWE-1274	Secure boot integrated	Weakness mitigated. Details of implementation not defined in the manual.	EDR 3.14: System Integrity – Integrity of the Boot Process	Ensure volatile memory protection is enough to prevent modification.
CWE-1263	No physical tampering method indicated on the manufacturers specification.	No physical control in place for tampering alert or alarm present. This could be transferred under the end user's (or asset owners) responsibility to enforce this control.	EDR 3.11: System Integrity – Physical Tamper Resistance and Detection	Incorporate an anti-tamper mechanism. Action an alarm/alert on tamper detection. Integrity protection level environment dependent. GPIO interface available for alarm/alert inputs and outputs on tampering detection.
CWE-1326	No apparent secure firmware updates integrated by the manufacturer.	The firmware or software should be validated on download/update action.	EDR 3.12 & 3.13: System Integrity – Provisioning Supplier/Asset Owner Roots of Trust	Source code for software/firmware and their subsequent updates should only be actionable from a trusted source and validated accordingly.

Security Gap Evaluation:

There are four main vulnerabilities related to this device that may require attention, no specifically defined security controls are immediately indicated, these are CWE-94, 494, 1191 & 1326. Additional investigation into these weaknesses and the available security features is required to identify the relevant controls intended purpose and capability in protecting the device.

Potential impact caused to the device or connected cloud infrastructure (resulting in business economic, reputational or technical impacts) should these weaknesses be exploited, could be high to very high or even catastrophic for the business. The potential impacts are also dependent on the application environment and accountable assets.

Various recommendations are stated in the final column of Table 1, these should be taken into consideration for implementation or further consideration in the software design to improve the devices overall security. Implementation of these controls would in effect provide additional means of controlling the aforementioned weaknesses and increase the overall device security.

CWE-1274 is sufficiently mitigated by the available and integrated security features, Secure boot integration. Recommended mitigation for CWE 1263 would be by the end-user and dependent on the actual installation or surrounding environment of product installation.

Security Gap Analysis ~ Threat Modeling

Key to early threat detection & mitigation:

The initial security gap analysis exercise is derived by means of utilising a threat modeling approach. The subject device is critically analysed for associated threats, weaknesses and applicable control recommendations then implemented for mitigation. These are readily available by means of creating or depicting the software or device architectural diagram with the corresponding components and services. In this particular exercise the device architecture only consists of the subject embedded device component. Considering the entire system would involve further investigation into the associated services, data flows and cloud components to which the device pertains.

Reflection

This exercise has exposed vulnerable areas that leave the device open to potential attacks. The security gap analysis has highlighted the essential requirement of identifying security issues of an embedded device at any phase of the life cycle.

Threat modeling enables a designer, security champion, developer or security engineer to anticipate expected threats and weaknesses specific to the subject device. In this way, providing the threat modeling exercise is executed during the design/development phases, will engrain the security controls early in the design of any software, firmware or hardware. Threat modeling is not only limited to the development phases, this activity can be conducted at any stage of a device’s lifecycle; testing, production, even during maintenance or service phases.