Risk Assessment and Threat Modeling

Introduction

Connected devices combine sensors, embedded software, communications networks, cloud services, mobile applications and human users. This distributed character creates value, but it also creates many points at which confidentiality, integrity, availability, safety and privacy may be harmed. A temperature sensor, for example, may appear low risk when considered alone; however, false readings from that sensor could cause an industrial control system to overheat equipment or could lead a medical platform to make an unsafe decision.

Risk assessment and threat modeling provide systematic ways to understand these possibilities before selecting security controls. Risk assessment asks: What can go wrong, how likely is it, and how serious would the consequences be? Threat modeling asks: Who could cause it, by what path, and which weaknesses would be exploited? Together, they help an organisation prioritize limited security resources rather than applying the same controls to every device.

This chapter develops a practical method for identifying IoT assets, analysing threats, estimating likelihood and impact, modelling attack paths, and selecting proportionate controls. Numerical ratings are decision-support tools, not statements of certainty. They must be supported by technical evidence and regularly reviewed.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Identify IoT assets, owners, dependencies and security requirements.
2. Distinguish assets, threats, vulnerabilities, events, impacts and risks.
3. Apply qualitative likelihood-impact analysis and a risk matrix.
4. Use STRIDE to structure threat identification.
5. Construct and interpret an attack-path model.
6. Prioritize risks and select proportionate preventive, detective and corrective controls.
7. Explain limitations, ethical responsibilities and governance requirements in IoT risk assessment.

1. Foundations of IoT Risk

An asset is anything that has value to an organisation or stakeholder. In IoT, assets include physical devices, firmware, cryptographic keys, sensor data, actuator commands, gateways, networks, cloud APIs, mobile applications, identities, logs, facilities and human safety. An asset may be tangible or intangible.

A threat is a potential cause of harm, such as an attacker, malicious insider, malware, equipment failure, poor configuration, extreme weather or accidental disclosure. A vulnerability is a weakness that can be exploited or triggered. Examples include default passwords, unsigned firmware, exposed debug ports, outdated libraries and excessive API privileges.

A threat event occurs when a threat uses or encounters a vulnerability. The resulting consequence is an impact. Risk expresses the possibility of a harmful outcome under specified conditions. A useful conceptual relationship is:

Likelihood and impact may be expressed qualitatively (such as Low, Medium and High) or quantitatively. The relationship is not a physical law: it is a structured decision model. Ratings should use documented scales, consistent definitions and evidence.

IoT security must address more than the traditional confidentiality, integrity and availability (CIA) triad:

• Confidentiality: preventing unauthorised access to data.
• Integrity: preventing unauthorised or incorrect alteration of data or commands.
• Availability: ensuring systems and services remain usable.
• Authenticity: establishing that a device, message or update is genuine.
• Safety: preventing physical injury, environmental damage or unsafe operation.
• Privacy: limiting collection, inference, use and disclosure of personal information.
• Resilience: maintaining essential functions and recovering after disruption.

In IoT, integrity and safety can be especially important. A forged actuator command may be more dangerous than the disclosure of a non-sensitive sensor reading.

2. Scoping the Assessment

A useful assessment begins with a clearly defined system boundary. The boundary should identify the physical location, device types, communication paths, cloud services, administrative interfaces, external suppliers and assumptions. A vague scope produces incomplete results.

A practical IoT inventory records:

Asset identification should include owners and custodians. The owner decides the acceptable level of risk; the custodian operates or protects the asset. Dependencies must also be documented. For example, a smart-building access controller may depend on a network switch, identity provider, cloud API, time service and battery backup.

Data-flow diagrams are particularly useful. Show sources, processing components, storage, trust boundaries and destinations. Trust boundaries indicate where assumptions change—for example, from a sensor’s local network to a public cloud or from a supplier-managed service to an organisation-managed system.

3. Security Requirements and Impact Analysis

Before rating threats, determine what must be protected and why. A requirement may be technical, operational, legal, contractual or safety-related. Examples include:

• only authorised technicians may change device configuration;
• firmware updates must be authenticated and recoverable;
• personal location data must be retained only as long as necessary;
• an emergency shutdown must remain available during loss of cloud connectivity;
• audit records must support investigation.

Impact analysis considers the consequence if a requirement fails. Relevant impact dimensions include financial loss, service interruption, safety, privacy, legal exposure, environmental harm, reputation and recovery effort. Impacts should be assessed for realistic scenarios, not merely for the worst imaginable outcome.

A simple impact scale might be:

The scale must be adapted to the domain. In a medical or industrial environment, safety consequences may dominate financial considerations. In a consumer device, privacy and large-scale deployment may dominate.

4. Likelihood Assessment

Likelihood estimates how plausible it is that a threat scenario will occur during a defined period. Assessment should consider attacker capability, motivation, exposure, exploit availability, physical access, existing controls, detectability and the number of deployed devices.

A five-level scale can be defined as follows:

The assessment should state its assumptions. “Likely” has little meaning without a time horizon, such as one year of operation. Ratings should also distinguish between the likelihood of an attempted attack and the likelihood of successful harm.

5. Risk Matrices and Prioritization

A risk matrix combines likelihood and impact. For integer ratings from 1 to 5, a basic risk score is:

where R is the risk score, L is likelihood, and I is impact. The score is dimensionless because the ratings are ordinal decision categories, not physical measurements. Therefore, a score of 12 is not necessarily twice as serious as a score of 6.

One possible interpretation is:

These thresholds are organisational choices. A low numerical score must not override a legal requirement or a safety prohibition. A separate “catastrophic impact” rule may require treatment even when likelihood is low.

Worked Example

Suppose a smart pump accepts commands through an exposed API. Analysts estimate likelihood as 4 (likely) and impact as 5 (severe), because unauthorised commands could create an unsafe operating condition.

The risk is critical under the example scale. Suitable treatment could include mutual authentication, authorisation by least privilege, command validation, network restriction, local safety interlocks, alerting and tested emergency operation. The objective is not simply to reduce the score; it is to reduce the underlying possibility or consequence of harm.

Risk treatment options are:

• Avoid: discontinue the unsafe function or do not deploy the system.
• Mitigate: reduce likelihood or impact using controls.
• Transfer or share: use contracts or insurance, while recognising that responsibility for safety and privacy cannot be completely outsourced.
• Accept: consciously retain the risk within approved tolerance.

Residual risk is the risk remaining after controls. Acceptance should be documented by an accountable authority, with conditions and review dates.

6. STRIDE Threat Modeling

STRIDE is a threat-identification mnemonic originally associated with Microsoft security engineering. It helps analysts consider common classes of threats:

STRIDE should be applied to system elements and data flows, not used as a checklist detached from architecture. For each component, ask which identities interact with it, what data crosses boundaries, how commands are authorised, and how evidence is recorded.

For example, a gateway receiving firmware updates may face spoofing of the update server, tampering with the image, information disclosure of keys, denial of service during update, and elevation of privilege through a vulnerable update agent. Repudiation may arise if update logs are incomplete or not time-synchronised.

STRIDE does not fully capture every IoT concern. Physical destruction, supply-chain compromise, safety hazards, privacy inference and environmental threats may require additional analysis. STRIDE is therefore a structured starting point, not a complete risk assessment.

7. Attack-Path Modeling

An attack path describes how an adversary could move from an initial condition to a harmful objective. A path may contain reconnaissance, initial access, exploitation, credential acquisition, lateral movement, privilege escalation and action on the target. It can be represented as a directed graph in which nodes are states or assets and edges are actions or conditions.

Consider this illustrative path:

Public scanner → exposed device interface → default credential → gateway → cloud API token → actuator command

The model reveals that the final harm depends on several linked weaknesses. Breaking any critical link may prevent the path. Analysts should identify:

1. Entry points: radio interfaces, web APIs, maintenance ports, supply-chain channels and cloud consoles.
2. Prerequisites: physical access, valid credentials, network position or a vulnerable version.
3. Privilege transitions: movement from a sensor account to gateway administration or cloud control.
4. Chokepoints: authentication gateways, certificate validation, command brokers and safety interlocks.
5. Detection opportunities: failed logins, unusual firmware, abnormal command rates and unexpected geographic activity.
6. Objectives: data theft, surveillance, fraud, disruption, unsafe actuation or persistence.

Attack-path modelling supports prioritization more effectively than counting vulnerabilities. A medium-severity weakness that connects several exposed systems may be more important than an isolated high-severity weakness with no feasible path to a valuable asset.

A simple attack-path table can record the path, prerequisites, controls and residual concern:

Attack trees can express alternative routes using OR branches and combined prerequisites using AND branches. Analysts should avoid assuming that every theoretical route is equally practical. Evidence, cost, skill and existing controls must inform the assessment.

8. Selecting Proportionate Controls

Controls should address the specific risk and should be layered. Important IoT controls include:

Identity and access control: assign unique device identities; use strong authentication; apply least privilege; separate operator, maintenance and service roles; rotate and revoke credentials.

Secure communications: use authenticated encryption where appropriate; validate certificates; protect against replay; avoid relying on network location as proof of identity.

Device security: disable unused services; protect debug interfaces; use secure boot where feasible; restrict local privileges; store keys in protected hardware when justified by the threat.

Secure updates: authenticate and, where appropriate, sign firmware; verify version and compatibility; prevent rollback to vulnerable versions; maintain recovery paths and update records.

Network architecture: segment devices by function and trust; restrict east-west traffic; limit internet exposure; monitor gateways and brokers.

Application and API security: validate inputs; enforce object-level authorisation; rate-limit sensitive operations; protect secrets; log administrative actions.

Monitoring and response: collect useful, integrity-protected logs; establish alert thresholds; maintain vulnerability disclosure and incident-response processes; test containment and recovery.

Safety and resilience: use local fail-safe behaviour, command bounds, manual override and operation during loss of cloud connectivity. Security controls must not create unsafe dependence on a single remote service.

A proportionate control balances risk reduction, cost, usability, reliability and residual risk. For a low-value environmental sensor, a managed password and network isolation may be adequate. For a life-safety controller, stronger identity, signed updates, independent safety mechanisms, rigorous testing and formal change control may be necessary.

9. Illustrative Case: Connected Cold-Chain Monitoring

Background

A logistics company deploys battery-powered temperature sensors in refrigerated containers. Sensors transmit readings through a cellular gateway to a cloud dashboard. Staff receive alerts when temperature exceeds a limit. The system supports food quality and regulatory reporting.

Problem

An assessment finds that sensors use a shared manufacturing password, the cloud API accepts long-lived tokens, and alerts depend entirely on cloud connectivity. A malicious person could inject false readings, suppress an alert or obtain shipment-location data.

Analysis

Assets include temperature data, shipment identity, location, alerting service, device credentials and the refrigeration process. The principal requirements are integrity and availability of alerts, confidentiality of commercial and location data, and reliable evidence for compliance.

Using STRIDE, spoofing is possible through shared passwords; tampering through forged telemetry; information disclosure through overly broad tokens; denial of service through cellular or API flooding; and repudiation through incomplete audit records. An attack path is:

Physically accessible sensor → shared password → forged telemetry → cloud API → false normal reading → delayed intervention.

The likelihood is assessed as 4 and impact as 4 because sensors are widely accessible and a spoiled shipment could cause substantial loss. The initial score is:

Approach and solution

The company assigns unique device identities, replaces shared passwords with certificate-based authentication, scopes tokens to one device and function, rejects impossible readings, protects messages in transit, records tamper-evident audit events and alerts on identity anomalies. Gateways buffer readings locally during cloud outages, while staff receive a separate escalation for communication failure. Physical access is restricted where practical, and the supplier provides a vulnerability-reporting and update process.

Outcome

The attack path is interrupted at several points. Forged telemetry becomes more difficult, excessive API access is removed, and loss of cloud connectivity becomes detectable rather than silently interpreted as normal conditions. Residual risks remain, including sensor failure and cellular disruption, so calibration, maintenance and manual inspection continue.

Learning points

The case demonstrates that risk concerns systems rather than isolated devices. Integrity and availability may matter more than confidentiality; a communication failure can itself be a safety or quality event; and layered controls are more reliable than one authentication mechanism.

10. Governance, Ethics and Limitations

Risk assessments involve judgement. Analysts must disclose uncertainty, avoid manipulating ratings to obtain a preferred decision, and include affected stakeholders. Privacy assessments should consider whether IoT data can reveal habits, movements, health conditions or household occupancy. Data minimisation, purpose limitation, retention controls and transparent notice are important ethical practices.

Organisations should align assessments with applicable laws, contracts and sector requirements. Depending on context, relevant guidance may include ISO/IEC 27001 risk-management practices, ISO/IEC 27400 for IoT security and privacy, NIST cybersecurity guidance, national critical-infrastructure rules and data-protection law. A framework does not replace legal advice or engineering validation.

Important limitations include:

• ordinal scores can create false precision;
• threat intelligence becomes outdated;
• unknown vulnerabilities cannot be rated reliably;
• supplier and inherited cloud risks may be poorly visible;
• rare catastrophic events may be undervalued by arithmetic;
• controls can introduce new failure modes;
• interconnected systems can produce cascading impacts.

Assessments should therefore be reviewed after significant architecture, supplier, threat or regulatory changes, and after incidents or near misses. Tabletop exercises, penetration tests, configuration reviews and recovery tests provide evidence that complements paperwork.

11. Contemporary Practice

Modern IoT programmes increasingly use software bills of materials to understand component dependencies, automated asset discovery, continuous vulnerability monitoring and machine-readable security advisories. Behaviour analytics and machine learning may help detect unusual device activity, but they do not prove that an event is malicious. Models can generate false positives, inherit biased training data and expose sensitive telemetry. Human review, explainable response criteria and secure handling of monitoring data remain necessary.

Edge computing can reduce cloud dependence and latency, but it introduces more local software and update responsibilities. Digital twins may improve modelling and testing, but an inaccurate twin can produce misleading conclusions. Zero-trust approaches encourage explicit authentication, authorisation and continuous evaluation rather than implicit trust based on network location. These approaches are useful, but they still require sound identities, safe defaults and operational competence.

Chapter Summary

IoT risk assessment begins with a defined scope, an asset and dependency inventory, and clear security, privacy and safety requirements. Threats exploit vulnerabilities to create events and impacts; risk is commonly prioritised by combining likelihood and impact, while recognising that ratings are judgement-based and not precise measurements. Risk matrices support consistent decisions, but catastrophic impact and legal obligations may require treatment regardless of score.

STRIDE structures analysis around spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Attack-path models show how weaknesses combine to reach valuable assets or harmful actions. Effective treatment uses layered, proportionate controls including identity management, secure communication, signed updates, segmentation, monitoring, resilience and safety interlocks. Assessments must account for privacy, supply chains, uncertainty, changing threats and residual risk, and must be reviewed throughout the system life cycle.

Key Terms

Asset: Something of value that requires protection.

Attack path: A sequence of conditions and actions leading to an attacker objective.

Availability: The property of being accessible and usable when required.

CIA triad: Confidentiality, integrity and availability.

Control: A safeguard that reduces likelihood, impact or both.

Impact: The consequence of a harmful event.

Integrity: Protection against unauthorised or incorrect alteration.

Likelihood: An estimate of how plausible an event is within stated conditions.

Residual risk: Risk remaining after controls are applied.

Risk: The possibility of harm arising from a threat scenario.

Risk matrix: A structured grid combining likelihood and impact ratings.

Risk treatment: Avoiding, mitigating, sharing or accepting risk.

STRIDE: A threat-modeling mnemonic covering six common threat categories.

Threat: A potential cause of harm.

Threat event: An occurrence in which a threat exploits or encounters a weakness.

Trust boundary: A point where security assumptions or control responsibilities change.

Vulnerability: A weakness that may be exploited or triggered.

Zero trust: An approach that requires explicit, continuing verification rather than implicit network trust.

Review Questions

Short Answer Questions

1. Distinguish between a threat, vulnerability and impact.
2. Why is asset ownership important in an IoT risk assessment?
3. List the six STRIDE categories.
4. What is residual risk?
5. Give two examples of safety-related IoT controls.

Long Answer Questions

1. Explain how an organisation can move from asset identification to a completed risk-treatment plan.
2. Describe the strengths and limitations of a five-by-five risk matrix.
3. Explain how trust boundaries and data-flow diagrams support IoT threat modeling.
4. Compare preventive, detective and corrective controls using IoT examples.
5. Discuss why integrity and availability may be more important than confidentiality in some IoT systems.

Analytical / Application Questions

1. A smart door-lock platform has shared technician credentials, an internet-facing API and no local manual override. Construct an attack path, identify relevant STRIDE threats, and propose controls in priority order.
2. A medical monitoring device has likelihood 2 and impact 5 on a five-point scale. Calculate its risk score using R = L × I, then explain why the numerical result alone should not determine deployment.
3. Design a risk-assessment plan for a connected factory that includes asset inventory, stakeholder involvement, reassessment triggers and evidence required to validate controls.

Multiple Choice Questions with Answers

Question 1

Which item is an example of an IoT asset?

A. Only a physical sensor

B. Only the cloud server

C. A device, its firmware, data, keys and supporting services

D. Only a user account

Correct Answer: C. A device, its firmware, data, keys and supporting services

Question 2

What does the integrity property primarily protect?

A. Unauthorised alteration of data or commands

B. Continuous electrical power

C. Physical ownership of a device

D. Removal of all personal data

Correct Answer: A. Unauthorised alteration of data or commands

Question 3

Using the chapter’s basic model, what is the risk score when likelihood is 4 and impact is 5?

A. 9

B. 16

C. 20

D. 25

Correct Answer: C. 20

Question 4

Which STRIDE category concerns impersonating a legitimate device?

A. Tampering

B. Spoofing

C. Repudiation

D. Denial of service

Correct Answer: B. Spoofing

Question 5

Which action best interrupts an attack path involving default device passwords?

A. Increase screen brightness

B. Use unique device identities and replace default credentials

C. Store more telemetry

D. Disable audit logging

Correct Answer: B. Use unique device identities and replace default credentials

Question 6

Why should risk scores not be interpreted as precise measurements?

A. They always use physical units

B. Likelihood and impact ratings are judgement-based ordinal categories

C. They cannot include impact

D. They are valid only for cloud systems

Correct Answer: B. Likelihood and impact ratings are judgement-based ordinal categories

Question 7

Which control is most directly associated with secure firmware updates?

A. Signed firmware verification

B. Longer device names

C. Publicly shared passwords

D. Removing version information

Correct Answer: A. Signed firmware verification

Question 8

What is a trust boundary?

A. A location where security assumptions or responsibilities change

B. A physical wall around every sensor

C. A list of approved suppliers

D. A device battery threshold

Correct Answer: A. A location where security assumptions or responsibilities change

Question 9

Which is an example of a resilience control in the cold-chain case?

A. Buffering readings locally during cloud outages

B. Using one shared password

C. Allowing unrestricted API tokens

D. Removing communication-failure alerts

Correct Answer: A. Buffering readings locally during cloud outages

Question 10

What is the principal purpose of attack-path modeling?

A. To count devices without considering relationships

B. To show how weaknesses can combine to reach a harmful objective

C. To replace all penetration testing

D. To guarantee that no vulnerability exists

Correct Answer: B. To show how weaknesses can combine to reach a harmful objective