11 Attack Scenarios: Defensive Method

An attack scenario is useful when it tests whether a threat model is specific enough to act on. It is not a misuse recipe. A good scenario record names the protected asset, the condition that makes harm plausible, the trust boundary involved, the control that should reduce the risk, the evidence that supports the control, and the trigger that requires retest.

The important shift is from narrative to evidence. A dramatic story about an attacker is not a review. A scenario record asks a bounded question: what condition is being reviewed, what evidence would confirm or weaken the control claim, what mitigation fits the condition, and what residual risk remains.

For example, a warehouse gateway might review the condition "an enrolled sensor identity can publish readings outside its assigned zone." The packet names telemetry and the dispatch record as assets, the device-to-gateway publish boundary, the expected topic or route authorization, the schema validation rule, accepted-message evidence, denied out-of-zone evidence, and residual risk if only the gateway enforces the rule. Retest is triggered by a topic change, schema change, gateway rule change, or dispatch-decision change.

Think of a fire drill. The point is not to set a real fire; it is to test whether the alarm sounds, the exits open, and people respond, and to record what failed. A scenario does the same for security controls: it checks whether the expected control and its evidence exist, without performing the attack.

The reader is about to apply A Scenario Is a Defensive Review Packet; first the relevant roles must be distinguishable. Figure 11.1 distinguishes them while showing how “The scenario loop: asset, condition, boundary, expected control, evidence, mitigation decision, residual risk, and retest trigger” is explicit in the diagram.

At Figure 11.1, Condition is not interchangeable with allowed and denied, and when it changes shows why the distinction matters. That specific contrast demonstrates “The scenario loop: asset, condition, boundary, expected control, evidence, mitigation decision, residual risk, and retest trigger” is explicit in the diagram. Carry it into A Scenario Is a Defensive Review Packet as the criterion for the next decision.

The One-Minute View

Beginner Examples

Overview Knowledge Check

If you can describe a scenario as a defensive evidence packet, you can stop here. Continue to Practitioner to build one and match a mitigation.

Start with the asset and a reviewed condition stated in defensive terms. Then mark the boundary, name the control expected there, and collect evidence for both the allowed case and the denied case before deciding on a mitigation.

Walkthrough: From Asset to Retest Trigger

Scenario Families and Their Evidence

Scenarios group by the security question they test. The families below are prompts for evidence-bound review, not a list of every possible threat. Select a mitigation because it fits the condition, not because it is generally good.

Availability scenarios include denial-of-service conditions where a service cannot answer legitimate devices or users. In a simple DoS review, one source or path overwhelms capacity or sends malformed traffic that the receiver cannot handle safely. In a DDoS review, many compromised devices send the pressure at once; when those devices are centrally controlled they form a botnet. The Mirai lesson is the defensive pattern: default or weak credentials plus reachable services can turn ordinary IoT devices into attack traffic, so the evidence should cover unique credentials, constrained remote access, rate behavior, monitoring, isolation, and recovery.

Scenario Mechanisms: Entry, Cascade, Concealment, and Power-State Error

Threat names become actionable when the review distinguishes their mechanisms. A protocol vulnerability is normally an entry condition, not the final objective: malformed or unexpected protocol state reaches vulnerable code, and a successful exploit may create a foothold for credential theft, persistence, data access, or a later availability attack. Evidence therefore has two layers—proof that malformed state is rejected or patched, and proof that post-compromise behavior such as new processes, changed firmware, or unusual outbound traffic is detected.

A privileged command path creates a different cascade. The first device accepts a console or management action beyond the caller's authority; its stored credentials, neighbor reachability, or management role can then put peer devices at risk. The denied-case test is not only “does this command fail for an ordinary user?” but also “can one compromised node invoke the same action on another?” Least privilege, per-device credentials, administrative segmentation, and peer-to-peer denial logs break that chain at different boundaries.

A stepping-stone host changes attribution. The intermediary is already compromised and relays later traffic, so the visible source is not necessarily the origin. Review synchronized logs at ingress, egress, identity, and target boundaries; preserve request identifiers or other correlation evidence; and constrain outbound traffic from systems that do not need arbitrary Internet access. The goal is to recover the path and contain the relay, not to trust the nearest source address.

Botnet DDoS separates victim and compromised fleet. Vulnerable IoT devices are recruited first, often automatically, and only later receive a coordinated instruction that floods a different service. This creates two protected assets: the device estate must not become attack infrastructure, and the external or internal target must remain available. Unique credentials, closed management exposure, patching, egress policy, fleet-behavior analytics, rate limits, and target-side capacity controls address different halves of that scenario.

Battery telemetry shows how a small data-integrity failure becomes a control failure. A false-high state suppresses conservation while the real charge falls, so the node can deplete unexpectedly and shut down without completing its final report. A false-low state triggers conservation too early, reducing sample rate, radio duty cycle, actuator availability, or user-facing performance despite adequate energy. Review physical supply access and the software measurement path separately, compare reported charge with voltage/current/coulomb evidence, bound impossible state jumps, and make the application record which degraded mode each threshold activates.

IP Control-Plane and Session Cases

An IoT path often crosses a low-power network, a translating gateway, an enterprise network, and a cloud service. Each boundary changes the available security evidence. The low-power link may have small frames and constrained key management; the gateway terminates one protocol and originates another; enterprise routing decides where packets can travel; and the application layer carries the identity or session that authorizes the final action.

Figure 11.2 sketches that path and pins each of this section’s cases to the boundary it exploits, so the table that follows can be read as a walk from left to right along the same pipeline.

Anchoring matters more than naming in Figure 11.2. SOURCE-ADDRESS SPOOFING hangs off the enterprise network because that is where ingress filtering can catch an impossible prefix, and SESSION-TOKEN REPLAY attaches to the cloud application because no link-layer control can revoke a stolen bearer token. The figure’s footer — review gateway outward — is the same order the closing paragraph of this section prescribes.

The review sequence is gateway outward. Confirm the low-power link's peer and freshness checks, then the gateway's translation and authorization rules, then routing and ICMP policy, and finally the application session. Encrypting only the last hop cannot repair a spoofed field message already accepted by the gateway, while link security alone cannot stop a stolen cloud-session token.

Use Taxonomies to Check Coverage

Threat taxonomies are useful after the scenario family is named because they reveal missing assets or paths. A broad taxonomy may group threats as physical, resource, personnel, and technical conditions. In IoT reviews the technical bucket often expands into credential discovery, privilege escalation, cryptanalysis, denial of service, data capture or manipulation in transit, and application exploitation through code injection, reverse engineering, input manipulation, or API abuse. Those labels are prompts for review evidence; they are not findings until they are tied to a concrete asset and boundary.

An IoT asset pass should cover more than the device. Include infrastructure such as routers, gateways, power supply, firewalls, access brokers, IDS or IPS, and authentication systems; platform and backend services such as web services, cloud infrastructure, data mining, data processing, device management, and usage records; information at rest, in transit, and in use; device hardware, firmware, software, sensors, and actuators; companion ecosystem devices such as phones, tablets, management consoles, and embedded systems; and communications assets such as LAN, WAN, VPN, PAN, Bluetooth LE, Zigbee, Z-Wave, Wi-Fi, MQTT, CoAP, LoRaWAN, 6LoWPAN, and NB-IoT.

A threat pass can then look for nefarious activity or abuse, eavesdropping and hijacking, outages, IT-asset loss, failures or malfunctions, disasters, and physical attacks. Typical rows include malware, exploit kits, targeted attacks, DDoS, counterfeit devices, privacy attacks, information modification, man-in-the-middle paths, IoT communication protocol hijacking, interception, network reconnaissance, session hijacking, replayed messages, software vulnerabilities, third-party failures, device modification, and sabotage. The scenario record should state which affected assets are in scope and which are deliberately out of scope.

For impact ranking, use the scenario wording to keep the review concrete: controller-to-actuator link compromise, sensor value or threshold manipulation, actuator setting sabotage, administration-system takeover, protocol-vulnerability exploitation, privileged command injection through a system console, stepping-stone hosts, botnet DDoS, power-source or battery-reading manipulation, and ransomware. Rank these by the protected action and consequence in the local system; "high" or "crucial" only matters when the evidence shows which people, processes, devices, or services would be affected.

Threat Impact Is a Consequence Claim

A useful impact scale separates consequence from likelihood and detectability. Crucial means the scenario can compromise safety, essential operation, privileged control, or large amounts of sensitive information. High means serious confidentiality or trust damage with bounded operational scope. Medium still requires treatment, but the immediate consequence is narrower or recovery is more practical. The inherited baseline below is a coverage prompt; every project must rerank it against its own assets and operating context.

The rank labels stay abstract until they sit next to each other. Figure 11.3 places the ten inherited families around one smart-building estate, so a reviewer can see at a glance that DDoS starts at CRUCIAL while Network outage starts only at MEDIUM — and then ask whether local evidence supports either rank.

Read Figure 11.3 by colour before reading it by name. The five CRUCIAL families — Malware, Exploit kits, Weak / default passwords, DDoS, and Data leakage & modification — share one property: each can reach privileged control, essential operation, or bulk sensitive data. The MEDIUM band is the one to challenge hardest; the figure’s own footer says to rerank every family against local assets, which is exactly what the hospital-gateway example below does to an APT label.

The last row illustrates why labels are not universal scores. An advanced persistent compromise of a hospital gateway would not remain “medium” merely because a generic taxonomy placed APT there. Preserve the baseline for traceability, then record the local consequence, affected population, duration, recovery path, and evidence that justified the final rank.

Affected-Assets Matrix: Abuse, Interception, and Hijacking

Read each row from mechanism to asset. A checked category is not proof that every instance is affected; it is a prompt to trace the concrete path and either include that asset in the scenario or state why it is out of scope.

Fourteen prose rows are hard to hold in working memory, so Figure 11.4 compresses the abuse and interception families into one dot grid: a filled dot means the asset class is in scope for that threat, a small grey dot means it usually is not.

Two contrasts in Figure 11.4 carry the section’s argument. Malware fills the Platform / backend column but leaves Comms empty, while On-path relay (MitM) does the opposite — the code-execution threat lives in endpoints and services, the interception threat lives in the channel. And only Protocol hijacking and Message replay reach the Decision-making column: a hijacked session or a replayed authentic message can flip an automated action without damaging any single device.

Affected-Assets Matrix: Outages, Loss, Failure, Disaster, and Physical Attack

The second matrix family is about reach rather than intent. Figure 11.5 keeps the same seven asset columns and shows how far each outage, malfunction, disaster, or physical attack travels.

The extremes of Figure 11.5 teach the lesson. Device failure fills exactly one column — a local fault with a local fix — while Loss of support services is drawn as a full-width band because identity, DNS, time, power, update, or cloud support can silently underpin every other asset. Between those poles, Third-party failure spans four columns, which is why the rows below ask about propagation paths rather than single points of damage.

Use the matrices twice. First, sweep across a threat row and confirm every affected asset has an owner, boundary, control, and recovery claim. Then sweep down an asset class and confirm it has scenarios for abuse, interception, outage, failure, and physical loss. Those two directions expose different omissions: a threat with an unowned consequence, or an important asset with no scenario at all.

The long asset and threat lists become useful only when a reviewer can test their coverage systematically. Figure 11.6 supplies that check: it links each STRIDE category to the property at risk and then to a mitigation family, so an omitted scenario or unsupported control is easier to spot.

Work across Figure 11.6 by matching a category, its consequence, and the control beneath it. Spoofing means “pretending to be someone or something else” and points to Authentication; Tampering means unauthorized modification and points to Integrity. Farther right, Denial of Service threatens Availability, whereas Elev. of Privilege threatens Authorization. The mitigation strip then names evidence directions such as S: MFA, PKI, T: Hashing, MAC, and D,E: Controls. Carry those pairings into the critical-scenario records below, where each taxonomy label must be attached to a real asset, boundary, consequence, and testable mitigation.