Security: Threats & Defense · Study deck

IoT Security Architecture

An IoT security architecture is not a generic system diagram with locks added to it.

Shield Shelly is your guide for this deck.

iot-securitysecurity-architecturetrust-boundaries

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: Encrypting the local link is not complete until both peers authenticate each other, weak protocol versions are disabled, and packet capture or test output confirms that sensitive payloads are not readable on the field network.
Explain: For example, "device to gateway" may require device identity, transport protection, replay resistance, payload validation, and connection logs. "operator to management service" may require strong authentication, role authorization, change approval, and audit trails.
Explain: That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.

Major section

Architecture Review Lens

That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.

This lens keeps the chapter focused on security architecture.
The chapter can now use Architecture Review Lens as an engineering criterion.

Major section

Trust Boundaries

Every boundary should have a named control and evidence.

For example, "device to gateway" may require device identity, transport protection, replay resistance, payload validation, and connection logs. "operator to management service" may require strong authentication, role authorization, change approval, and audit trails.
The boundary is also where overclaims often appear.
Encryption across one link does not prove that a command is authorized.
A signed update does not prove that rollback and recovery are defined.

Major section

Attack Paths as Architecture Tests

An attack path is a route from an entry point to a protected asset.

The goal is not to provide misuse instructions.
The goal is to check whether the architecture still limits harm when one control is weak, bypassed, or misconfigured.

A security architecture evidence loop traces one protected asset path through flow, trust boundary, control placement, evidence, review decision, record, and design feedback.

Major section

Common Pitfalls

Layer names are useful only when they are tied to assets, flows, controls, and evidence.

A diagram with "device," "network," and "service" labels does not show whether commands are authorized or whether failures are detected.
Several controls may all depend on the same administrative account, credential store, or policy path.

Major section

Common Pitfalls (continued)

If that dependency fails, the layers may fail together.

Maintenance accounts, update services, configuration dashboards, and support workflows often have high authority.
A security architecture that reviews only telemetry paths can miss the routes that change system behavior.
Encryption can protect data in transit or at rest, but it does not decide who may invoke a command, subscribe to a topic, change a setting, or approve an update.

Major section

The Weakest Path Sets the Risk

IoT security is not a feature you add to one component; it is a property of the entire path from sensor to cloud.

But the flip side is unforgiving: an attacker does not attack your strongest control, they attack your weakest, taking the cheapest path to the goal.
This reframes where effort should go.

Major section

The Weakest Path Sets the Risk (continued)

The overall strength is closer to the minimum of the layers than the sum.

A reviewable architecture also has to show the path being protected.
This prevents a layer diagram from becoming decoration; every box and arrow must answer a security question.
The first frames the issue, the second changes or constrains it, and the third makes the result visible.

Major section

Trace the Cheapest Path Before You Spend

Assess a design by listing each layer's controls and tracing the cheapest path an attacker could take to the goal.

The strongest security investment is whatever raises the current weakest layer, not whatever improves an already-strong one.
They log into the device with the default password, read the unencrypted local traffic, and reach the data - never touching the strong layers.
Pouring more budget into the already-excellent cloud changes nothing.

Major section

Trace the Cheapest Path Before You Spend (continued)

These evidence checks keep the review from rewarding work that sounds secure but does not change the cheapest path.

Fixing the default credential and encrypting the local link - the two weakest layers - is what actually raises the system's security.
For each row, write the asset affected, the boundary crossed, and the observable proof you would expect after the fix.
When budget is limited, separate urgent exposure from architectural cleanup.

Major section

Trace the Cheapest Path Before You Spend (continued)

Replacing a default password is not complete until provisioning shows unique credentials, old shared credentials are refused, and logs prove failed attempts are visible.

Encrypting the local link is not complete until both peers authenticate each other, weak protocol versions are disabled, and packet capture or test output confirms that sensitive payloads are not readable on the field network.
A weakness off the protected path may still matter, but it should not outrank the path an attacker can already use.
Defense in depth works only when every layer is credible, because the attacker always probes for the one that is not.

Major section

Trust Starts With a Verifiable Root

Trust cannot be stronger than its anchor or its weakest link, the same principle as the layers above.

The chain is anchored in hardware - a boot ROM plus a fused key or key hash that an attacker cannot alter.
The subtlety is that the chain is only as trustworthy as its weakest verification.
The answers decide whether "secure boot" and "hardware key storage" are real architecture controls or just product labels.

Major section

Trust Starts With a Verifiable Root (continued)

Likewise, if the anchor is not truly immutable - an unlocked bootloader, a root key that was never fused - an attacker can replace the foundation and forge the entire chain.

The complementary discipline is least privilege: authentication proves who a component is, but authorization must still limit what it may do, so a compromised or spoofed component cannot pivot beyond its role.
Immutable anchor The root must be a fused key and boot ROM an attacker cannot change, or the whole chain can be forged.
Least privilege Authentication proves identity; authorization must still bound what each component can do.

Major section

Summary

Security architecture is the connection between a threat model and a reviewable design.

It names protected assets, traces flows, marks trust boundaries, places controls, and records evidence.
The review should not accept a generic layer diagram as proof of security.
It should ask what each control protects, where it sits, what it depends on, and what evidence supports the claim.

Deck summary

Key takeaways

That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.

Every boundary should have a named control and evidence.
An attack path is a route from an entry point to a protected asset.
Layer names are useful only when they are tied to assets, flows, controls, and evidence.
If that dependency fails, the layers may fail together.

Retrieval practice

Recall check 1 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q1What makes an IoT security architecture reviewable rather than a decorated system diagram?

AIt traces a request from entry to the protected asset and names the controls on each path

BIt adds a small lock icon to every single box that is drawn in the diagram

CIt lists the brand and model of every device that is used in the whole system

DIt counts exactly how many firewalls the company currently owns and operates

Show answer

Answer: A A reviewable security architecture traces a request from entry to the protected asset and names the controls on each path.

Retrieval practice

Recall check 2 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q2A team shows an IoT architecture diagram with TLS between devices and a gateway, but no record of who may issue device commands after reaching the gateway. What is the most important review finding?

AThe architecture has transport protection, but the command authorization boundary is not evidenced.

BThe architecture is complete because encryption proves every command is allowed.

CThe gateway should be removed from the design because gateways cannot enforce security controls.

DThe review should ignore commands and focus only on telemetry data.

Show answer

Answer: A A security architecture review separates transport protection from command authorization and asks for evidence at each trust boundary.

Retrieval practice

Recall check 3 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q3A system has hardware-protected keys and multi-factor access in the cloud, but ships devices with a default admin password. How secure is it overall?

AAbout as strong as the default password

BVery secure, because the cloud controls are excellent.

CSecure, because the average of the layers is high.

DImpossible to say without knowing the encryption algorithm.

Show answer

Answer: A Security is a whole-system property bounded by the weakest layer.

Retrieval practice

Recall check 4 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q4In the deployment above, where should the next security budget go to most improve overall security?

AFix the default password and encrypt the weak local link.

BAdd more monitoring to the already-strong cloud.

CUpgrade the cloud's encryption algorithm.

DNothing; the strong cloud already secures the system.

Show answer

Answer: A Overall security is set by the weakest layer, and the cheapest path runs through the default credential and the unencrypted link.

Retrieval practice

Recall check 5 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q5A device has secure boot: ROM verifies the bootloader, which is correctly signed. But the bootloader then loads the application without checking its signature. What is the security consequence?

ATrust stops at the unsigned application; attackers can replace it.

BThe device is fully secure because the bootloader was verified.

CThe application inherits trust automatically from the signed bootloader.

DOnly the bootloader can be attacked, not the application.

Show answer

Answer: A Secure boot depends on every stage verifying the next.

Print reference

Answers 1 of 2

Answer key.

A · A reviewable security architecture traces a request from entry to the protected asset and names the controls on each path.
A · A security architecture review separates transport protection from command authorization and asks for evidence at each trust boundary.
A · Security is a whole-system property bounded by the weakest layer.
A · Overall security is set by the weakest layer, and the cheapest path runs through the default credential and the unencrypted link.

Print reference

Answers 2 of 2

Answer key.

A · Secure boot depends on every stage verifying the next.