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: 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: The chain needs a protected trust anchor; one common design uses boot ROM with a fused key or key hash, while other designs can use a protected key in a secure element.
Explain: Immutable anchor The root must be protected against unauthorized change, for example with a fused key and boot ROM, or the whole chain can be forged.

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.
Figure: A security architecture evidence loop traces one protected makes three checkpoints explicit: Asset, test, playbook, and record limits.

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.
If that dependency fails, the layers may fail together.
Maintenance accounts, update services, configuration dashboards, and support workflows often have high authority.

Major section

The Weakest Path Sets the Risk

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

IoT security is not a feature you add to one component; it is a property of the entire path from sensor to cloud.
This reframes where effort should go.
A reviewable architecture also has to show the path being protected.

An IoT security architecture review maps protected assets, data and command flows, trust boundaries, controls, and operational evidence.

Major section

The Weakest Path Sets the Risk (continued)

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 prevents a layer diagram from becoming decoration; every box and arrow must answer a security question.
The important evidence in Figure: An IoT security architecture review maps protected assets is the relationship among actuator: Identity, and trust boundary.
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

The chain needs a protected trust anchor; one common design uses boot ROM with a fused key or key hash, while other designs can use a protected key in a secure element.

The subtlety is that the chain is only as trustworthy as its weakest verification.
Likewise, if an attacker can replace the protected anchor or use an unlocked bootloader to bypass verification, they can break the chain even if the later stages are signed.
Trust cannot be stronger than its anchor or its weakest link, the same principle as the layers above.

Major section

Trust Starts With a Verifiable Root (continued)

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.

The answers decide whether "secure boot" and "hardware key storage" are real architecture controls or just product labels.
Immutable anchorThe root must be protected against unauthorized change, for example with a fused key and boot ROM, or the whole chain can be forged.
Least privilegeAuthentication 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

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.
The overall strength is closer to the minimum of the layers than the sum.
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.

Retrieval practice

Recall check 1 of 6

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 labels security controls on the components in the system diagram

CIt inventories device models and their documented security features, then groups them by product family and network segment

DIt lists firewall placements around the IoT network segment

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 6

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

Q2An unauthorized device command crosses the device-to-gateway boundary; which controls belong at that boundary?

AA firewall rule count without a denied-command test at the gateway.

BDevice identity, command authorization, and message validation with tests.

CA dashboard style change without validating device-origin commands.

DEncrypt cloud storage because protected records also secure commands as they cross system boundaries.

Show answer

Answer: B These checks address who sent the command and whether it may act.

Retrieval practice

Recall check 3 of 6

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

Q3Three security controls all depend on the same admin account; what should an attack-path review record?

AThree independent defenses merely because they have distinct names.

BProof that commands are authorized even if the admin account fails.

CA shared admin dependency that could collapse all three controls.

DAn absence of residual risk because three controls are listed.

Show answer

Answer: C One compromised account could defeat several apparent layers.

Retrieval practice

Recall check 4 of 6

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

Q4A 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?

AVery secure, because the cloud controls are excellent.

BSecure, because the average of the layers is high.

CAbout as strong as the default password

DImpossible to say without knowing the encryption algorithm.

Show answer

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

Retrieval practice

Recall check 5 of 6

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

Q5A deployment has a default device admin password and an unencrypted local link, while its cloud uses MFA and hardware-protected keys. Where should the next security budget go to most improve overall security?

AAdd more monitoring to the already-strong cloud.

BUpgrade the cloud's encryption algorithm.

CNothing; the strong cloud already secures the system.

DFix the default password and encrypt the weak local link.

Show answer

Answer: D 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 6 of 6

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

Q6A 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.
B · These checks address who sent the command and whether it may act.
C · One compromised account could defeat several apparent layers.
C · Security is a whole-system property bounded by the weakest layer.
D · 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.