Chapter 14 — Security architecture and engineering: methods I

Chapter 14 — Security architecture and engineering: methods I

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 STRIDE on the portal"]
  N2["14.2 Recording the results"]
  N3["14.3 Reviewing with the developer"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 STRIDE on the portal"]
  N2["14.2 Recording the results"]
  N3["14.3 Reviewing with the developer"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 STRIDE on the portal]
    |
    v
[14.2 Recording the results]
    |
    v
[14.3 Reviewing with the developer]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) apply STRIDE to the upload portal design; (2) record threats and mitigations; (3) review the result with the developer.

14.1 STRIDE on the portal

Brightwater builds the manifest upload portal recommended in chapter 12. Tomás applies STRIDE from Shostack (2014) to its design. Spoofing: a criminal could pose as a retailer, so accounts need strong sign-in. Tampering: a manifest could be altered in transit, so uploads use HTTPS. Repudiation: a retailer might deny uploading a change, so uploads are logged with the account. Information disclosure: one retailer must not see another's manifests. Denial of service: huge files could overload the import. Elevation of privilege: a retailer account must not reach admin functions.

14.2 Recording the results

Tomás records each threat in a table with the element affected, the mitigation, the owner and how the mitigation will be tested. Some mitigations already exist in the portal framework, such as HTTPS. Others need work: a file size limit, per-retailer data separation checked by a test, and multi-factor sign-in for retailer accounts. He marks one item, address-change spikes, as needing business input on what counts as unusual. A table makes the review traceable and gives the developer a checklist.

14.3 Reviewing with the developer

Tomás walks through the table with the developer in thirty minutes. The developer points out a threat Tomás missed: the portal's password reset emails could be intercepted if a retailer's email is compromised. They add a mitigation: reset links expire in fifteen minutes and notify the account's second contact. The developer also challenges one mitigation as excessive. Joint review improves the result because developers know how the code really behaves, and technologists bring a structured view of threats. They agree to repeat the review whenever the portal design changes.

Worked example

Tomás applies STRIDE to the portal, records six threats with mitigations and tests, and reviews them with the developer, who adds a reset threat.

Synthetic case. The portal is synthetic; Shostack (2014) is real.

Errors and limits

STRIDE finds categories, not every attack. Reviews depend on available time.

Exercises

• EX040 — Information disclosure. What information disclosure threat did Tomás find? Rubric: 3 = one retailer seeing another's manifests;; 2 = cross-retailer;; 1 = vague;; 0 = none.
• EX041 — Business input item. Which item needed business input? Rubric: 3 = defining unusual address-change spikes;; 2 = spikes;; 1 = vague;; 0 = none.
• EX042 — Missed threat. What threat did the developer add? Rubric: 3 = interception of password reset emails;; 2 = reset;; 1 = vague;; 0 = none.

Synthesis

STRIDE gives structure, and joint review with developers catches threats either side would miss alone.

Continue studying — chapter 14 of 30

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →