2  Threats Route Map

security
threats
iot
Keywords

IoT security route map, security threats module, threat modeling path, IoT vulnerabilities, security controls

2.1 Start With the Failed Alarm

Picture a cold-chain gateway that should warn a team when vaccines get too warm. The dashboard says everything is fine, but the box arrived spoiled. A useful security review does not begin with “add encryption” or “run a checklist.” It begins with the story: which reading, command, credential, alert, or log could be spoofed, changed, hidden, delayed, or denied?

This route map keeps that story in order. Name the asset and boundary first. Then ask what could go wrong, where the weakness might live, which control actually matches the risk, and what evidence would prove the control worked.

Keep each threat attached to a concrete failure mode, not to a vague fear that the system is “insecure.”

2.2 In 60 Seconds

This page is the route map for the Security Threats and Vulnerabilities module. Use it to choose a path through security foundations, threat modeling, attack and vulnerability analysis, controls, practice, and review. The module is evidence-bound: a security claim should name the asset, threat, weakness, control, and validation evidence that supports it.

This index does not replace the detailed chapters. It helps you decide where to start and what kind of evidence each chapter family should produce.

2.3 Learning Objectives

By the end of this page, you will be able to:

  • Choose the right security-threats chapter group for a learner question.
  • Separate security foundations from threat modeling, attack analysis, controls, and review.
  • Connect assets, threats, vulnerabilities, controls, and validation evidence.
  • Avoid treating one control or one checklist as proof that a system is secure.
  • Use practice and visual-resource chapters after the core evidence path is clear.

2.4 Key Ideas Before You Choose a Chapter

  1. Security review starts by naming what must be protected.
  2. Threat modeling identifies who or what could cause harm and how.
  3. Vulnerability review identifies weaknesses in devices, software, networks, data flows, and privacy-sensitive behavior.
  4. Controls reduce specific risks; they do not prove safety on their own.
  5. Monitoring, testing, and review evidence are needed before accepting a security claim.

2.5 Prerequisites

  • Basic networking vocabulary: address, port, protocol, gateway, and firewall.
  • Basic system architecture vocabulary: device, network, service, data flow, and user boundary.
  • IoT Security Fundamentals if CIA, assets, controls, or attack surface are unfamiliar.

2.6 Follow the Evidence Route

Read the module as a review path: scope first, model threats, inspect weaknesses, select controls, and validate the result.

Security Threats route map with five numbered stages on a vertical path: (1) Security Foundations, 7 chapters; (2) Threat Modeling, 6 chapters; (3) Network Security and Defense, 3 chapters; (4) Device and Hardware Security, 3 chapters; (5) Secure Development, 4 chapters.
Figure 2.1: Security Threats module route map: five numbered stages from security foundations and threat modeling through network, device, and secure-development defenses, each labeled with its chapter count.

Use the map in this order:

  1. Start with assets, boundaries, and security goals.
  2. Build a threat model before choosing controls.
  3. Review vulnerabilities against the threat model.
  4. Match controls to specific threats and weaknesses.
  5. Validate with monitoring, tests, exercises, or review records.

2.7 Choose the Chapter Lane

Security foundations:

Threat modeling:

Attacks and vulnerabilities:

Security controls:

Practice, review, and support:

2.8 Pick the First Question

Choose based on the question:

  • “What are we protecting?” Start with security fundamentals and architecture.
  • “What could go wrong?” Start with threats introduction and threat modeling.
  • “Which category does this weakness fit?” Start with OWASP IoT Top 10 or STRIDE.
  • “How could an attack move through the system?” Start with attack scenarios.
  • “Which control fits this risk?” Start with defense in depth, segmentation, secure boot, updates, or protocol security.
  • “How do we know the control is working?” Start with monitoring, labs, assessments, or worked examples.

2.9 Keep Claims and Proof Separate

Keep these boundaries visible while reading:

  • A framework category is not evidence that a control is present.
  • A control description is not evidence that the control was configured correctly.
  • A lab result is not evidence for an unrelated architecture.
  • A case study is useful for reasoning, but it is not proof that another system has the same risk.
  • Monitoring evidence supports detection claims, not prevention claims.
  • Compliance vocabulary should be connected to a concrete requirement and review record before it is used as a conclusion.

2.10 Check Before You Accept a Claim

Before using a chapter as support for a security claim, check that:

  • the protected asset or data flow is named;
  • the threat or weakness category is specific;
  • the proposed control maps to that threat or weakness;
  • the chapter separates design intent from validation evidence;
  • local links stay inside the relevant learning path;
  • figures stand alone with captions and do not depend on old generated diagrams;
  • interactions test security reasoning, not generic labels or code blanks.

2.11 Mistakes That Break the Story

  • Jumping to tools or checklists before naming assets and boundaries.
  • Treating one security control as complete protection.
  • Treating threat categories as if they were mitigations.
  • Treating a diagram as proof that traffic is isolated or monitored.
  • Mixing prevention, detection, and response evidence.
  • Pulling in broad claims from case studies without matching evidence.

2.12 Knowledge Check

2.13 Matching Quiz

2.14 Ordering Quiz

First Name the Thing That Could Be Hurt

Security work fails when it starts from "add some protections" instead of "what are we actually defending, against whom?" Threat modelling is the disciplined step of answering, before building: what do we protect, who might attack it, how could they, and what would stop them? Its output is a prioritised list of threats, each paired with a mitigation.

The foundation is the CIA triad — the three properties security protects: Confidentiality (secrecy), Integrity (data unaltered), and Availability (accessible when needed). Every threat is, at heart, an attack on one of these three. A framework called STRIDE turns the vague "how might this be attacked?" into a systematic checklist.

Security Threats route map with five numbered stages: security foundations, threat modeling, network security and defense, device and hardware security, and secure development, each labeled with its chapter count.
Security-threats review route: scope assets and boundaries, model threats, inspect vulnerabilities, choose controls, and validate with evidence.

For an IoT product, that route keeps the review tied to observable work. A cold-chain gateway, for example, might protect shipment temperature readings, command topics, device credentials, and audit records. The first question is not whether the design has "security", but which of those assets crosses a trust boundary and what failure would harm the mission. A spoofed sensor threatens integrity, a leaked token threatens confidentiality, and a flooded gateway threatens availability. The map then forces a separate evidence trail for each claim instead of one broad conclusion.

Use this module index as a triage tool. If the learner cannot name the asset or boundary, start with foundations. If the asset is clear but the failure modes are vague, move to threat modeling and STRIDE. If the likely weakness is already known, use the attack and vulnerability chapters. If a control has been proposed, jump to segmentation, secure boot, updates, protocol security, monitoring, or the relevant practice chapter and ask what record would prove the control works.

Intuition: threat modelling is a pre-mortem. Instead of waiting to be breached and asking why, you sit down first and imagine every way an attacker could win — then close each path before it is used.

Overview Knowledge Check

Use STRIDE to Turn Worry Into Rows

STRIDE names six threat categories, each the violation of a security property, which points straight at the mitigation:

STRIDE threat Violates Typical mitigation
Spoofing Authentication Strong auth, MFA
Tampering Integrity Signatures, AEAD, MACs
Repudiation Non-repudiation Signed audit logs
Information disclosure Confidentiality Encryption, access control
Denial of service Availability Rate limiting, redundancy
Elevation of privilege Authorization Least privilege, isolation

A practitioner pass should turn each category into a local question. Spoofing is not just "someone could impersonate a device"; it asks which device identity is accepted by the broker, gateway, or API, where credentials live, and which log entry proves a rogue identity was rejected. Tampering asks which message, firmware image, configuration file, or database row could be modified and which signature, MAC, hash, or review record would detect it. Information disclosure asks which field is sensitive, where it is stored, who can read it, and whether transport and at-rest controls are both relevant.

Do the same for availability and privilege. A denial-of-service concern should identify the constrained component, such as an MQTT broker connection pool, CoAP endpoint, gateway CPU, battery budget, or cellular data quota. Elevation of privilege should identify the role boundary, such as installer, tenant admin, service technician, cloud operator, or device process. A useful STRIDE table therefore has columns for asset, data flow, trust boundary, threat, likely weakness, proposed control, owner, and validation evidence. If any row cannot name evidence, it is still a hypothesis.

Worked example: modelling a device-to-gateway link

Walk the data flow (device -> gateway) through STRIDE:

  Spoofing:  a rogue device impersonates a real one
             -> mitigate with per-device authentication
  Tampering: an attacker alters sensor packets in transit
             -> mitigate with authenticated encryption (AEAD)
  Info disc: an eavesdropper reads the readings
             -> mitigate with encryption (e.g. DTLS)
  DoS:       flooding the gateway with junk packets
             -> mitigate with rate limiting / cookies

Each threat now has a concrete, checkable control.

The power of STRIDE is that it converts "is this secure?" into six specific questions with specific answers, so nothing is left to a vague sense of safety.

Practitioner Knowledge Check

Rank the Exposed Paths Before You Build Controls

A threat model is only useful if it drives the right work, and a few principles keep it grounded.

Trust boundaries and attack surface

Threats concentrate where data crosses a boundary — device to gateway, user to API. Reducing the attack surface (fewer exposed interfaces, closed ports) removes threats outright rather than merely mitigating them.

Prioritise by risk

Not all threats are equal. Rank them by likelihood times impact so limited effort goes to the ones that matter, instead of spreading thin across every theoretical possibility.

Defence in depth

Layer controls so no single failure is fatal: authentication, encryption, least privilege, monitoring. If one layer is bypassed, the next still stands.

Assume breach

Design as if some layer will be defeated. Segmentation, least privilege, and logging limit how far an attacker who gets in can spread and how long they go unnoticed.

Attack surface is the set of reachable ways an attacker can interact with the system: radio join procedures, debug headers, update services, cloud APIs, mobile apps, certificates, dashboards, open ports, and third-party integrations. In a resource-constrained IoT design, reducing that surface can be more reliable than adding compensating controls everywhere. Removing an unused service, disabling a debug interface, narrowing a firewall rule, or separating tenant command topics can eliminate whole rows from the threat model.

Prioritisation is also more than a red-yellow-green label. A risk score should say why likelihood and impact were judged that way: exposure to the public internet, physical access assumptions, credential reuse, fleet size, safety consequence, recovery time, and monitoring coverage. A smart-meter command channel and a classroom air-quality dashboard may both use MQTT, but the impact, attacker value, and acceptable residual risk are different. The model should keep those differences visible instead of copying the same control checklist into both systems.

So the threats module is a loop, not a one-off: enumerate threats with STRIDE across your trust boundaries, prioritise them by risk, assign each a concrete control, and layer those controls assuming some will fail. The deliverable is never "we added security" but "here are the threats we identified, ranked, and the specific mitigation for each" — a claim you can review and test. After implementation, the same model becomes the retest plan: run the denied-command test again, inspect the broker or gateway logs, verify alerts still fire, and reopen the row when firmware, roles, topology, or data sensitivity changes.

Under-the-Hood Knowledge Check

2.15 Summary

The Security Threats and Vulnerabilities module is best read as an evidence path. Foundations define assets and boundaries. Threat modeling names what could go wrong. Vulnerability chapters show where weaknesses appear. Control chapters connect mitigations to risks. Practice and review chapters help you test whether the claim is actually supported.

2.16 Key Takeaway

Use the security-threats module as a route from foundations to threat modeling, controls, monitoring, updates, labs, and review evidence.

2.17 Concept Relationships

2.18 What’s Next

Start with IoT Security Fundamentals if the vocabulary is new. Move to IoT Threats Introduction when the next task is to identify threats. Use Defense in Depth Controls when the question is how controls should combine, and use Threats Worked Examples when you need practice applying the review path.