Chapter 9 — Security architecture and engineering: leadership and assurance | Postgraduate 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.

Chapter 9 — Security architecture and engineering: leadership and assurance

Lesson map

Lesson 09 published. Map, example, EX041.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Leading the programme"]
  N2["9.2 Assurance for the board"]
  N3["Lab — Counting designed, implemented and verified co"]
  N4["9.3 Honest metrics"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX041"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Leading the programme"]
  N2["9.2 Assurance for the board"]
  N3["Lab — Counting designed, implemented and verified co"]
  N4["9.3 Honest metrics"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX041"]

[Learning outcomes]
    |
    v
[9.1 Leading the programme]
    |
    v
[9.2 Assurance for the board]
    |
    v
[Lab — Counting designed, implemented and verified co]
    |
    v
[9.3 Honest metrics]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX041]

Learning outcomes

You will (1) lead an architecture team through a multi-year programme; (2) provide assurance to a board; (3) use metrics that show progress honestly.

9.1 Leading the programme

Priya now leads a team of three architects through a three-year segmentation and access programme. She sets principles everyone can apply without asking her: deny by default, identity before network, exceptions dated and owned. She delegates decisions within those principles and reviews only exceptions. Weekly, the team shares one design and one failure. She protects time for learning, because health technology changes faster than any single architect can follow. Leadership in architecture is mostly about making good decisions possible without the lead in every room.

9.2 Assurance for the board

The board asks a simple question: are we safer than last year? Priya answers with assurance rather than reassurance. She reports what has been verified, by whom and how, using the risk management framework vocabulary of NIST SP 800-37 Rev. 2 for authorisation and continuous monitoring. Independent internal audit tests a sample of controls each quarter. She distinguishes three levels: designed, implemented and verified. Only verified controls count as reducing risk in her report, which makes progress look slower but far more trustworthy.

Lab — Counting designed, implemented and verified controls

# Count programme controls by assurance level (synthetic register).
levels = ["verified"] * 19 + ["implemented"] * 10 + ["designed"] * 7 + ["planned"] * 4
designed = sum(l in ("designed", "implemented", "verified") for l in levels)
implemented = sum(l in ("implemented", "verified") for l in levels)
verified = levels.count("verified")
print(f"controls {len(levels)}: designed {designed}, implemented {implemented}, verified {verified}")
print(f"verified share {verified/len(levels):.0%}")

Run with python3 lab_assure.py. Verified output:

controls 40: designed 36, implemented 29, verified 19
verified share 48%

9.3 Honest metrics

The lab shows the gap between levels. Of forty programme controls, thirty-six are designed, twenty-nine implemented and nineteen verified. Reporting thirty-six would flatter the programme; reporting nineteen shows where effort is needed. Priya also reports clinics fully segmented and the median age of open exceptions. The board initially prefers the larger figure but comes to trust the smaller one after audit confirms it. She notes that a metric earns trust when it occasionally delivers bad news. The verified share was 48 percent at the time.

Worked example

Priya sets team principles, reports assurance at three levels with independent audit sampling and shows the board verified rather than designed counts.

Synthetic case. Team, controls and figures are synthetic; SP 800-37 Rev. 2 is real.

Errors and limits

Verification samples may miss failures. Metrics can be gamed once targets are set.

Exercises

EX041 — Delegation principle. What principles let the team decide without Priya? Rubric: 3 = deny by default, identity before network, dated owned exceptions;; 2 = two;; 1 = vague;; 0 = none.
EX042 — Three levels. What three levels does Priya distinguish? Rubric: 3 = designed, implemented and verified;; 2 = two;; 1 = vague;; 0 = none.
EX043 — Lab counts. What were the counts at each level in the lab? Rubric: 3 = 36 designed, 29 implemented, 19 verified;; 2 = partly;; 1 = vague;; 0 = none.
EX044 — Assurance versus reassurance. What makes Priya's reporting assurance rather than reassurance? Rubric: 3 = it reports what has been verified, by whom and how;; 2 = verification;; 1 = tone;; 0 = none.
EX045 — Trusted metric. When does a metric earn trust, according to Priya? Rubric: 3 = when it occasionally delivers bad news;; 2 = bad news;; 1 = always green;; 0 = none.

Synthesis

Architecture leadership delegates through principles and offers assurance based on verified, not designed, controls.

Continue studying — chapter 09 of 12

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