Chapter 16 — OT, IoT and cyber-physical security: methods II
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 A quick threat-modelling pass"]
N2["16.2 Product baseline questions"]
N3["16.3 Reading vendor claims"]
N4["16.4 Assumptions"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 A quick threat-modelling pass"]
N2["16.2 Product baseline questions"]
N3["16.3 Reading vendor claims"]
N4["16.4 Assumptions"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 A quick threat-modelling pass]
|
v
[16.2 Product baseline questions]
|
v
[16.3 Reading vendor claims]
|
v
[16.4 Assumptions]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) apply a simple threat-modelling pass to the logger system; (2) assess an IoT product against ETSI EN 303 645 provisions; (3) review vendor documentation for security claims; and (4) record assumptions that the model depends on.
16.1 A quick threat-modelling pass
Draw the logger system: loggers → radio → GW-LOG → firewall → vendor cloud → web portal used by the quality manager. At each arrow ask: can someone pretend to be the sender, change the data, read it, block it, or gain more control than intended? This prompt list, adapted from STRIDE, produces a short threat list in under an hour.
Priya's pass at NCS produced, among other entries, "radio replay of old readings", with the assumption that an attacker would need to be within about 100 m of the loggers.
16.2 Product baseline questions
ETSI EN 303 645 gives concrete questions for each IoT product: does it ship with a universal default password (5.1)? Does the vendor publish a way to report vulnerabilities (5.2)? Can its software be updated securely (5.3)? Does it communicate securely (5.5)? Is personal data protected (5.8)? The answers can come from documentation, a vendor questionnaire and, for some items, a bench check.
The logger vendor's answers to Priya's questionnaire: unique per-device passwords on labels (5.1 met), a disclosure page (5.2 met), signed updates applied only remotely by the vendor (5.3 met with a dependency), and TLS to the cloud but an unencrypted radio link (5.5 partly met).
16.3 Reading vendor claims
"Bank-grade encryption" is not an answer to 5.5; "TLS 1.2 or later with server certificate validation, certificates pinned to the vendor CA" is. Ask for specifics, and note when the vendor cannot provide them.
The NCS logger vendor's answer for 5.5 was specific enough to act on: TLS to the cloud, but no encryption on the radio link between loggers and GW-LOG. That "partly met" is more useful than a confident marketing phrase, because it tells Priya exactly where the compensating control must go: comparing logger readings with PLC probes, as in Chapter 18. A vendor who could only say "secure communication" would have left the radio link unexamined.
16.4 Assumptions
Threat models rest on assumptions: the radio link range is about 100 m; the portal uses MFA; the vendor's cloud is operated securely. Write them down; if one proves false, revisit the model.
Priya's list for the logger system includes the roughly 100 m radio range, which defines who can attempt a replay of old readings; the vendor's statement that it applies signed updates remotely, on which 5.3 depends; and the quality manager's portal using MFA, which she had not verified. If the portal turned out to have no MFA, "cloud account compromise" would move up her list, so the assumption is marked to be checked at the next vendor review.
Worked example (synthetic NCS)
Priya's vendor questionnaire returns: unique per-device password printed on the label (5.1 met); disclosure policy page exists (5.2 met); firmware updates signed but applied only by the vendor remotely (5.3 met with a dependency); TLS to cloud, but the radio link between loggers and gateway is unencrypted (5.5 partly met). Her threat list gains "radio replay of old readings" with the assumption "attacker within ~100 m".
Synthetic case — Northgate Cold Storage. The vendor's answers are invented.
Errors and limits
Questionnaire answers are claims; verify the most important ones. ETSI EN 303 645 targets consumer IoT; for industrial gateways IEC 62443-4-2 may be the better reference.
Exercises
- EX046 — STRIDE prompts at the portal. Give one spoofing and one information-disclosure threat for the quality manager's portal. Rubric: 3 = two plausible threats; 2 = one; 1 = generic; 0 = none.
- EX047 — A vague claim. Rewrite the question you would send back to a vendor who says "military-grade security". Rubric: 3 = specific question about protocol, versions, validation; 2 = partial; 1 = accepts claim; 0 = none.
- EX048 — Testing one assumption. How would you check the "about 100 m radio range" assumption safely? Rubric: 3 = vendor spec plus walk test with a receiver on a bench logger in permitted areas; 2 = partial; 1 = transmit to live loggers; 0 = none.
Synthesis
Quick threat modelling, baseline questions and written assumptions let a technologist assess an IoT product in days, not months.
Continue studying — chapter 16 of 30
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →