Embedded Device - Threat Model v1.0

[Qasim]

Embedded Device

Threat Model v1.0

Definition

An embedded device is a computer system having a microprocessor/microcontroller, memory, input/output peripheral device, along with a software that has a dedicated function within a larger mechanical or electronic system.

Basic Architecture

Context and Environment

When doing threat modeling, it is essential to have an in-depth context and understanding of the eco-system. Gather and add as much information as required/possible. This activity also helps in understanding the scope/boundary of the system for which threat modeling needs to be done.

Attribute	Examples
Device Name	xxxxxxx
Type of Device	standalone, networked, realtime etc
Technology Stack/Components	e.g. Device Model, OS, Firmware, Components
Purpose/Functionality	business use…
List of Users	end users, administrators
List of Systems/Components Connected	Integrated systems or components
Asset/Data Classification	from the perspective of Confidentiality, Integrity, Availability & Privacy
Installation Location	Car, Road, Factory, Home, Office
Device Physical Exposure	Public, Internal, Restricted, Private
Criticality	Mission, Safety, Time

Identify Applicable Threats & Mitigations

Select and brainstorm Threats and its Mitigations from below list for your device under review. It is essential to discuss with business, product, data owner and other applicable stakeholders and asking the questions:

“What can go wrong”?
“How we can prevent or minimize the impact of these threats?”

There can be multiple mitigation techniques to prevent various types of threats. Also, not all mitigation techniques will prevent the threats completely, instead they will be able to minimize the impact of the threats.

Check	Threat (what can go wrong?)	Mitigation (How we can prevent or minimize the impact of threat?)
	Command/Code Injection	Implement input validation. Apply allowed list. Do not use user input data directly in shell commands.
	Unauthorized Access/Use	Implement strong authentication/authorization on debug ports. Implement strong/complex passwords requirements on all interfaces. Implement strong device specific credentials/passwords. Avoid Common Password for all devices. Based on classification of device implement physical access controls. Implement Secure Credential Storage in the Device. Implement uniform response for invalid and valid username. Implement password recovery/reset through out of band channel e.g. separate recovery tools. Implement strong authorization and access control policy/procedure. Implement strong Cryptographic algorithm over outdated ones.
	Malware Infection	Implement of Secure Boot. No firmware downgrade or unauthorized upgrade should be possible. The device should have the ability to patch the firmware in a secure way. Isolate hardware and software resources based on security domains.
	Buffer Overflow	Use safe language or apply best practice e.g. MISRA C, CERT C, C++ Restrict Memory Allocation, Switch to Readonly mode wherever possible, use of ASLR, ESP and Stack Canaries where possible to minimize the threat.
	Brute Force Access	Restrict Bad Login Attempts and implement lockout time and retry delays. Implement strong/complex passwords requirements on all interfaces.
	Data Theft/Exfiltration	Implement strong Cryptographic algorithm over outdated ones. Data processed or generated among various device states should not be by default accessible/available to other device states. Implement strong authentication/authorization on debug ports. Implement strong/complex passwords requirements on all interfaces. Implement strong device specific credentials/passwords. Avoid Common Password for all devices. Based on classification of device implement physical access controls. Implement Secure Credential Storage in the Device. Isolate hardware and software resources based on security domains. Implement uniform response for invalid and valid username.
	Side Channel Analysis/Attack	Protect the Device with Radio Frequency Shielding. Device operations should be consistent and independent of type of data processed. Power consumption should be independent of operating instructions.
	Reverse Engineering (H/W, S/W)	Implement physical security of the Device, classify and protect confidential device information. Implement Secure SDLC and protect Source Code and Binaries. Introduce Tamperproof Fixtures, Remove H/W component identifiers, Implement S/W Code Obfuscation Techniques and Removal of Debug ports.
	Fault Injection	Implement Redundant Execution of Critical Security Functions in the Software. Introduce Hardware Sensors to detect any Injection Attacks. Implement Physical Device Hardening including but not limited to Shielding from radio frequency and ultraviolet light.
	Device Reset to Insecure State	Based on classification of device, implement physical security controls. Increase Vigilance, Monitoring or Tamper detection controls e.g. sensors, alarms for unauthorized access. Implement audit logging based on type of device and software based alerting mechanism.
	Device Tampering/Theft	Based on classification of device, implement physical security controls. Increase Vigilance, Monitoring or Tamper detection controls e.g. sensors, alarms for unauthorized access.
	Denial Of Service	Implement a strategy to have dual/redundant power source. Follow software development best practices. e.g. MISRA C, CERT C, C++. Based on classification of device, implement physical security controls. Disable non-essential services, ports, protocols etc.
	Credential Theft/Leakage	Implement strong device specific credentials/passwords. Avoid Common Password for all devices. Implement Secure Credential Storage in the Device. Implement secure process to set device credentials. Minimize the credential exposure within the team members. Do not hardcode credentials in source code. Improve Software Quality Control, Strengthen Secure SDLC.
	Open Backdoors	Disable non-essential services, ports, protocols etc, keep software bill of materials. Improve Software Quality Control, Strengthen Secure SDLC. Ensure no debug/test functionality exists. Implement strong/complex passwords requirements on all interfaces. Implement authentication/authorization on debug ports.
	Privilege Escalation	Isolate hardware and software resources based on security domains. Implement Software Access Control Policies and/or Hardware enforced partitions e.g. ARM TrustZone. Implement strong authorization and access control policy/procedure.
	Device Reconnaissance	Implement physical security of the hardware, classify and protect confidential device information. Remove H/W component identifiers, Implement S/W Code Obfuscation Techniques and Removal of Debug ports. Increase Vigilance, Monitoring e.g. sensors, alarms for unauthorized access.
	Business Logic Bypass	Improve Software Quality Control, Strengthen Secure SDLC.
	Misconfigurations	Strengthen device commissioning, configuration and maintenance/change process. Improve Software Quality Control, Strengthen Secure SDLC.
	Undetected Suspicious Activities	Implement secure audit logging and alerting based on type of device and wherever possible. Strengthen device commissioning, configuration, maintenance/change process. Centralize and collect device audit logs in a tamper proof storage/system.
	Lack of Accountability	Implement secure audit logging based on type of device and wherever possible. Strengthen device commissioning, configuration, maintenance/change process. Centralize and collect device audit logs in a tamper proof storage/system.
	Malicious Hardware Additions	Based on classification of device implement physical security controls. Increase Vigilance, Monitoring or Tamper detection controls e.g. sensors, alarms for unauthorized access. Strengthen device commissioning, configuration, maintenance/change process.
	Power Failure	Implement a strategy to have dual/redundant and reliable power source.