Chapter 27 — Security architecture and engineering: verification

Chapter 27 — Security architecture and engineering: verification

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Planning verification"]
  N2["27.2 Choosing methods"]
  N3["27.3 Recording evidence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Planning verification"]
  N2["27.2 Choosing methods"]
  N3["27.3 Recording evidence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Planning verification]
    |
    v
[27.2 Choosing methods]
    |
    v
[27.3 Recording evidence]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) plan verification of security requirements; (2) use tests, reviews and scans appropriately; (3) record verification evidence.

27.1 Planning verification

For the click-and-collect service, Lucas writes security requirements as testable statements: a collection code must be required to release an order; codes must expire after fourteen days; staff app screens must mask phone numbers after collection; and the service must log every release with the staff member's identity. For each requirement he names a verification method and who performs it. Requirements written as vague goals, such as "the service must be secure", cannot be verified and give false comfort to everyone who reads them.

27.2 Choosing methods

Lucas matches methods to requirements. Code expiry is checked by an automated test with a clock set forward. Masking is checked by a reviewer using the staff app on a test account. Logging is checked by performing a release and reading the log. A dependency scan checks for known vulnerable libraries, as SP 800-218 recommends. He notes that scans find known issues but not logic flaws such as releasing an order without a code, which only a designed test can catch. Each method covers what it can.

27.3 Recording evidence

Every verification produces a record: date, method, result and who performed it. One test fails: codes do not expire because the expiry job was not scheduled in production. The developer fixes it and Lucas reruns the test. The record shows both the failure and the fix, which is more convincing to an auditor than a clean sheet. Lucas adds the tests to the release checklist so that future changes are verified again rather than assumed to have preserved the behaviour.

Worked example

Lucas writes four testable requirements, matches each to a verification method, finds an unscheduled expiry job and records the failure and fix.

Synthetic case. The service and results are synthetic; SP 800-218 is real.

Errors and limits

Tests verify only what they were designed to check. Evidence ages with each change.

Exercises

• EX079 — Untestable requirement. Why is "the service must be secure" a poor requirement? Rubric: 3 = it cannot be verified;; 2 = untestable;; 1 = fine;; 0 = none.
• EX080 — Scan limit. What can a dependency scan not find? Rubric: 3 = logic flaws such as release without a code;; 2 = logic flaws;; 1 = everything;; 0 = none.
• EX081 — Failed test. Which test failed and why? Rubric: 3 = code expiry; the job was not scheduled in production;; 2 = expiry;; 1 = masking;; 0 = none.

Synthesis

Verification needs testable requirements, matched methods and recorded evidence, including failures.

Continue studying — chapter 27 of 40

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →