Chapter 7 — Security architecture and engineering: controls and verification | Professional Security architecture and engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 07 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Selecting controls"]
  N2["7.2 Verifiable requirements"]
  N3["Lab — Tracing requirements to verification results"]
  N4["7.3 Checking they work"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Selecting controls"]
  N2["7.2 Verifiable requirements"]
  N3["Lab — Tracing requirements to verification results"]
  N4["7.3 Checking they work"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]

[Learning outcomes]
    |
    v
[7.1 Selecting controls]
    |
    v
[7.2 Verifiable requirements]
    |
    v
[Lab — Tracing requirements to verification results]
    |
    v
[7.3 Checking they work]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) select controls for top threats; (2) write verifiable requirements; (3) check that controls work.

7.1 Selecting controls

For the top repairs threats, Owen selects controls with the property team and IT. Key safe code exposure: show codes only to the assigned contractor on the visit day, as done in chapter 6, and log every view. Former contractor accounts: the expiring access workflow. Cross-contractor visibility: restrict each contractor account to its own jobs. Altered job notes: keep a change history that contractors cannot edit. He checks the selections against control families in NIST SP 800-53 Rev. 5, which confirms he has covered access control, audit and accountability.

7.2 Verifiable requirements

Owen turns controls into statements that can be checked: a contractor account can view only jobs assigned to its company; a key safe code is visible only on the visit date; every code view is logged with user and time; job note edits keep the previous version. Vague requirements such as "contractor access must be secure" cannot be tested. Writing them precisely also helps the vendor, who can confirm which ones the product supports and quote for any that need configuration.

Lab — Tracing requirements to verification results

# Trace requirements to verification results, before and after the vendor fix (synthetic).
reqs = {"R1 contractor sees own company's jobs only": "pass",
        "R2 key safe code visible only on visit date": "fail (visible until end of next day)",
        "R3 every code view logged with user and time": "pass",
        "R4 job note edits keep previous version": "pass"}
for r, res in reqs.items(): print(f"{r}: {res}")
print(f"round 1: {sum(v == 'pass' for v in reqs.values())}/{len(reqs)} passed")
reqs["R2 key safe code visible only on visit date"] = "pass (after vendor cutoff change)"
print(f"round 2: {sum(v.startswith('pass') for v in reqs.values())}/{len(reqs)} passed")

Run with python3 lab_trace.py. Verified output:

R1 contractor sees own company's jobs only: pass
R2 key safe code visible only on visit date: fail (visible until end of next day)
R3 every code view logged with user and time: pass
R4 job note edits keep previous version: pass
round 1: 3/4 passed
round 2: 4/4 passed

7.3 Checking they work

Owen and a tester use two test contractor accounts to check each requirement. The lab traces each requirement to its test result. Three pass. The code visibility test fails: codes remain visible for a day after the visit because the vendor uses the end of the following day as the cutoff. The vendor changes the setting and the retest passes. Owen records results in a table linked to the threats, so anyone can see which threats are treated by verified controls and which still depend on unverified promises.

Worked example

Owen selects controls for four threats, writes four testable requirements and verifies them, catching a code visibility cutoff error.

Synthetic case. Controls and tests are synthetic; SP 800-53 Rev. 5 is real.

Errors and limits

Test accounts may not reflect real data volume. Vendor settings can revert after updates.

Exercises

EX031 — Tamper control. Which control addresses altered job notes?
Show marking criteria
Rubric: 3 = a change history contractors cannot edit;; 2 = history;; 1 = vague;; 0 = none.
EX032 — Vague requirement. Why is "contractor access must be secure" a poor requirement?
Show marking criteria
Rubric: 3 = it cannot be tested;; 2 = untestable;; 1 = vague;; 0 = none.
EX033 — Lab coverage. What did the first test round show in the lab?
Show marking criteria
Rubric: 3 = 3 of 4 requirements passed; code visibility failed;; 2 = 3 of 4;; 1 = vague;; 0 = none.
EX034 — Failure cause. Why did the code visibility test fail?
Show marking criteria
Rubric: 3 = the vendor cut off at the end of the following day;; 2 = cutoff;; 1 = vague;; 0 = none.
EX035 — Retest result. What did the second round show in the lab?
Show marking criteria
Rubric: 3 = all 4 requirements passed after the vendor fix;; 2 = 4 of 4;; 1 = vague;; 0 = none.

Synthesis

Controls become trustworthy when written as testable requirements and verified with recorded results.

Continue studying — chapter 07 of 12

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →