Chapter 29 — Security architecture and engineering: operations

Lesson map

Lesson 29 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes"]
  N1["29.1 Architecture in operation"]
  N2["29.2 An operating rhythm"]
  N3["29.3 Changing safely"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["29.1 Architecture in operation"]
  N2["29.2 An operating rhythm"]
  N3["29.3 Changing safely"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]

[Learning outcomes]
    |
    v
[29.1 Architecture in operation]
    |
    v
[29.2 An operating rhythm]
    |
    v
[29.3 Changing safely]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes

You will (1) describe the operational activities that keep an architecture effective; (2) design a light operating rhythm for Fernway; (3) handle change without losing security.

29.1 Architecture in operation

Lucas learns that an architecture decays without operation. Accounts accumulate rights, certificates expire, suppliers change and new tools appear. NIST SP 800-37 Rev. 2 calls the ongoing part continuous monitoring: checking that controls still work and that risk stays acceptable. For Fernway this cannot mean a large team. Lucas lists the activities that matter most: access reviews, patching, backup tests, log review, supplier checks and incident drills. Each has a frequency and an owner, and each produces a small piece of evidence.

29.2 An operating rhythm

Lucas designs a calendar. Weekly: Hannah checks identity alerts and patch status. Monthly: the least-privilege checker from chapter 25 runs and results are reviewed; a backup restore is tested. Quarterly: supplier list review, tabletop exercise and a report to the board with the metrics from chapter 15. Annually: architecture overview refresh and risk review. He estimates the total at about four hours a week. Writing the rhythm down means tasks survive holidays and staff changes, because the calendar rather than memory carries them.

29.3 Changing safely

Fernway changes often: new stores, seasonal staff and new suppliers. Lucas adds security questions to the existing change form: does this change add a supplier, new data, a new boundary crossing or new privileged access? A yes triggers a short review with Hannah. Most changes answer no and pass quickly. During his placement, the questions catch a new loyalty app that would have received the full member list. The integration is redesigned to send only member numbers and points balances, which is all the app needs.

Worked example

Lucas lists operational activities, designs a four-hour-a-week rhythm and adds four security questions to the change form, catching an oversharing loyalty app.

Synthetic case. Rhythm and app are synthetic; SP 800-37 Rev. 2 is real.

Errors and limits

Rhythms slip under workload pressure. Change questions depend on honest answers.

Exercises

• EX085 — Why a calendar. Why write the operating rhythm down?
  Show marking criteria

  Rubric: 3 = tasks survive holidays and staff changes;; 2 = continuity;; 1 = vague;; 0 = none.
• EX086 — Change trigger. What triggers a security review of a change?
  Show marking criteria

  Rubric: 3 = adding a supplier, new data, a boundary crossing or privileged access;; 2 = trigger;; 1 = all changes;; 0 = none.
• EX087 — Loyalty app fix. How was the loyalty app redesigned?
  Show marking criteria

  Rubric: 3 = to receive only member numbers and points balances;; 2 = minimise;; 1 = vague;; 0 = none.

Synthesis

An architecture stays effective through a written operating rhythm and light security questions in change management.

Continue studying — chapter 29 of 40

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