Chapter 25 — Design studio I | Engineering Security governance, risk and compliance

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 25 — Design studio I

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 The brief"]
  N2["25.2 The design"]
  N3["25.3 Critique and revision"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 The brief"]
  N2["25.2 The design"]
  N3["25.3 Critique and revision"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 The brief]
    |
    v
[25.2 The design]
    |
    v
[25.3 Critique and revision]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) design a governance solution for a defined problem; (2) present it for critique; (3) revise it based on feedback from users.

25.1 The brief

In the first design studio, Nadia's team receives a brief from Ardwell: design a way to manage vendor remote access that satisfies security, keeps outage response fast and produces evidence for audits. The team interviews a control engineer, a vendor technician and the information security manager. Each wants something different. The engineer wants vendors connected within minutes during outages. The technician wants one sign-in, not five. The manager wants every session approved, logged and reviewed. These three positions become the design constraints for the next section: speed, a single sign-in and full accountability.

25.2 The design

The team proposes an access broker: vendors sign in with named accounts and multi-factor authentication, request a session for a specific device, receive approval from an on-call engineer through a phone app and work through a recorded jump host. Pre-approved emergency sessions are allowed during declared outages, with review the next day. Sessions end automatically after four hours. The design meets each stakeholder's main concern while removing the shared password and direct connection found earlier. Prof. Brenner points out that the pre-approved emergency path is the most likely route for misuse, so its next-day review must actually happen.

25.3 Critique and revision

At the studio review, a lecturer asks what happens if the phone app fails during a storm. Another asks who reviews recordings and how often. The team adds a backup approval by phone call with a logged reference and proposes sampling ten percent of recordings each month, focusing on emergency sessions. Nadia learns that critique is most useful when it tests the design against realistic failure, and that a design is not finished until its operation, including review, is planned. Sampling ten percent of recordings with a focus on emergency sessions puts review effort where approvals were weakest.

Worked example

Nadia's team designs a vendor access broker balancing speed, usability and evidence, then adds fallback approval and recording review after critique.

Synthetic case. The brief and design are synthetic.

Errors and limits

Studio designs skip cost detail. Stakeholder interviews are small samples.

Exercises

EX073 — Stakeholder wants. What did the control engineer want? Rubric: 3 = vendors connected within minutes during outages;; 2 = speed;; 1 = vague;; 0 = none.
EX074 — Session limit. How long can a vendor session last before ending automatically? Rubric: 3 = four hours;; 2 = 4h;; 1 = vague;; 0 = none.
EX075 — Recording review. How will recordings be reviewed? Rubric: 3 = sample ten percent monthly, focusing on emergencies;; 2 = sampling;; 1 = vague;; 0 = none.

Synthesis

Good governance designs balance stakeholder needs and plan for failure and review.

Continue studying — chapter 25 of 50

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