Firmware Threat Modeling Template

This repo includes templates that can be used while performing threat modeling using Microsoft Threat Modeling Tool. These templates are helpful if you are looking for a more firmware or hardware centric threat modeling using Microsoft Threat Modeling Tool (https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling).

Entities or Elements of a Firmware Threat Model

Modeling an API or Firmware Module

MS-TMT uses concept of Process to model a piece of code that perform one specific function. This templates follows the same trend. The firmware APIs or modules are modeled as Process.

Process

Process can be a firmware module like a firmware update module, or an internal key management module, or an interrupt handling module, or a protocol parser module, or an API that performs a very specific function.

Attributes of a Process

Attribute Name	Values	Description
Code Type	Third Party Code	The API or module belongs to a third party library
	Open Source Code	The API or module belongs to an open source library
	Home Grown Code	The API or module is developed by your organization
	Crypto Code	The API or module performs cryptographic operations like AES encryption, SHA3-256 Hashing, etc.
	Key Management Code	The API or module performs internal key management in the device
	User Credential Handling Code	The API or module takes user credential as input and perform computation on that data
	Includes Mathamatical Computation Code	The API or module perform mathamatical computation
Origin	Managed Code	The API or module is mainatined by your team
	Foreign Code	The API or module is not maintained by your team
Language	C	The API or module is written in C Programming Language
	C++	The API or module is written in C++ Programming Language
	C/C++	The API or module is written in mix of C and C++ Programming Language
	Rust	The API or module is written in Rust Programming Language
	Python	The API or module is written in Python Programming Language
	Other	The API or module is written in some other Programming Language
Running with	Kernel Privilege	Process is running in Kernel Mode
	Standard User with Elevation of Privilege	Process is running in user mode with a valid elevation of privilege
	Standard User without Elevation of Privilege	Process is running in strict user mode
Isolation Level	Has Separate Runtime Context	The process has its own runtime context i.e., stack, heap, registers, code section, and data section
	Has Separate Stack and Heap Memory	The process has a dedicated stack and heap memory
	Runs in Secure Enclave or is a part of TEE	The process runs as a part of secure enclave or is a part of the trusted execution environment
	Shares Runtime Context	The process shares its runtime context with other processes
Accepts Input from	External User or Entity	Process accepts input from host application or some other form of interaction with external user
	Remote User or Entity	Process accepts input from a remote user like remote firmware attestation tool or over-the-air firmware update tool, etc
	Another Process	Process accepts input from another process
	GPIO Pins	Process accepts inputs from general purpose input pins
	Debug Port	Process accepts inputs from debug port like JTAG or UART
	Not Applicable	The process does not take input
Affected by	HW or SW Interrupt	The process can be interrupted by a high priority interrupt routines
	HW Power Event	The process can be affected by unforeseen power events
	Aging	The process is affected by the aging of the hardware
	Eletromagnetic Disturbances	The process is sensitive to electromagnetic disturbances
	Extreme Temperature	The process is sensitive to huge temperature variation of environment
	Voltage Jitter	The process is affected by voltage glitches or voltage tampering
	Clock Jitter	The process is affected by clock glitch or clock signal tampering
Sanitizes Input	Yes	Process perform some form of input validation before consuming the input data
	No	Process consumes the input data without any input validation
	Not Applicable
Sanitizes Output	Yes	Process perform some form of output validation before returning the output data
	No	Process returns the output data without any output validation
	Not Applicable
Implements or Uses an Authentication Mechanism	Yes	Process perform some form of output validation before returning the output data. Entity authentication can be a very basic operation like checking module ID or checking possession of some kind of token or checking password. More, authentication can involve challenge-response protocol based interaction or ZKP based interaction or digital certificates (or certificate chain) verification
	No	Process does not perform any form of entity authentication before communicating with another process
	Not Applicable
Implements or Uses an Authorization Mechanism	Yes	Process perform some form of access control list check. Authorization can be achived by implementing access control mechanism or a ticket or a token based system
	No	Process does not perform any form of entity authorization before communicating with another process
	Not Applicable
Saves and Restores State or Context	Yes	Process saves runtime context in NVM and restores later
	No	Process does not save-restore runtime context
	Not Applicable
Handles User Credentials	Yes	Process perform some form of computation on user supplied credential like password
	No	Process does not handle user credential
	Not Applicable
Exception Handling Done	Yes	Process perform some form of exception handling
	No	Process does not perform any exceptional handling
	Not Applicable

Modeling Storage

A firmware code running in a typical microcontroller uses a varieties of memories. A process running in a typical microcontroller uses stack memory section, heap memory section, various level of instruction and data cache, DRAM memory, flash memory, etc.

Attributes of Data Storage

Attribute Name	Values	Description
Storage Type	SRAM	SRAM Primary Memory. Stack and heap section lives in this memory.
	DRAM	DRAM Memory
	OTP eFuse	One-time programmable (OTP) memory is a type of non-volatile memory (NVM) that commonly comprises of electrical fuse (eFuse) and antifuse. In relation to security, antifuse is better than eFuse because there is no visible difference between a programmed bit and unprogrammed bit.
	NAND or Optane	Non-volatile memory
	SPI Flash	Flash memory
	ROM	PROM or EPROM or EEPROM or Mask ROM
	HW Key Cache	A dedicated memory to store runtime keys
	Registers	CPU registers
	Cache	Instruction or data cache
Stores User Data	No	The memory does not store user data
	Yes	The memory stores user data
	Not Applicable
Stores Configuration Data	No	The memory does not store configuration data
	Yes	The memory stores configuration data
	Not Applicable
Stores Vendor Data	No	The memory does not store vendor data
	Yes	The memory stores vendor data
	Not Applicable
Stores Crypto Keys or Secrets	No	The memory does not store secrets
	Yes	The memory stores secrets
	Not Applicable
Part of Secure Encalve or TEE	No	The memory is not a part of secure hw enclave or trusted execution environment
	Yes	The memory is a part of secure hw enclave or trusted execution environment
	Not Applicable
Stores Log or Telemetry Data	No	The memory does not store log or telemetry data
	Yes	The memory stores log or telemetry data
	Not Applicable
Stores Critical Security Parameters	No	The memory does not store security critical data structures
	Yes	The memory stores security critical data structures which if leaked has a significant security consequences
	Not Applicable
Encrypted	No	The data in the memory is not encrypted
	Yes	The data in the memory is encrypted
	Not Applicable
Encrypted using Authenticated Encryption	No	The data in memory is not encrypted using authenticated encryption scheme
	Yes	The data in memory is encrypted using authenticated encryption scheme
	Not Applicable
Signed	No	The data in memory does not have digital signature to verify its authenticity
	Yes	The data in memory have digital signature to verify its authenticity
	Not Applicable
Read Only Access	No	The memory can be read and write
	Yes	The memory is read only
	Not Applicable
Read-Write Access	No	The memory does not have read-write access
	Yes	The memory can be read and written to
	Not Applicable
Backup	No	The memory does not hold back up data
	Yes	The memory content is a back up copy of some data
	Not Applicable
Shared	No	This is not a shared memory
	Yes	This is a shared memory or memory section
	Not Applicable
Stores Boot Code	No	This memory does not store boot code
	Yes	This memory stores boot code
	Not Applicable
Stores Firmware Code	No	This memory does not store firmware image
	Yes	This memory holds firmware image
	Not Applicable
Access Control Enforced	No	This memory does not have access control mechanism
	Yes	The content of this memory has some form of access control mechanism
	Not Applicable
Stores Credentials	No	This memory does not store credential data
	Yes	This memory stores credential data
	Not Applicable

Modeling Data Flow or Communication

The data flow between two APIs in an IoT firmware written in C/C++ happens in one of two ways, pass by value or pass by reference. In pass by value, data buffer is used to send message from caller to callee. In pass by reference, a memory location is used to pass value in both the directions. Besides these two methods there are other communication interfaces through which a firmware interacts with hardware or external entities like GPIO, Interrupt, Debug Port, various serial buses like SPI, CAN, I2C, etc.

Properties

Attribute Name	Values	Description
Medium	Data Buffer
	Memory Reference
	GPIO
	Interrupt
	Binary
	JTAG Payload
	UART Payload
	SPI Payload
	NVMe Payload
	NVMe MI Payload
	Request Signal
Source Authenticated	Not Applicable
	No
	Yes