Chapter 25 — Team project studio | Technologist 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 25 — Team project studio

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 The studio brief"]
  N2["25.2 Roles and review"]
  N3["25.3 Presenting"]
  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 studio brief"]
  N2["25.2 Roles and review"]
  N3["25.3 Presenting"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 The studio brief]
    |
    v
[25.2 Roles and review]
    |
    v
[25.3 Presenting]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) work in a student team on a shared security design; (2) divide roles and review each other's work; (3) present a team result.

25.1 The studio brief

Back at the polytechnic, Ruth runs a studio. Teams of four design security for a fictional pharmacy delivery service with a website, a mobile app for couriers and a small warehouse. Tomás's team includes a developer, a network student and a student interested in privacy. They have three weeks. The brief requires a zone diagram, data flows, risk scenarios, controls and a test plan. Working in a team mirrors real practice, where no one person covers every specialism. Ruth provides a short fictional company profile as the starting point.

25.2 Roles and review

The team assigns a lead for each deliverable but requires every piece to be reviewed by someone else. Tomás leads risk scenarios and reviews the network student's zone diagram, finding that couriers' phones were placed in the same zone as warehouse systems. The privacy student reviews his scenarios and adds one about prescription details visible on courier screens. Peer review catches errors and adds perspectives. The team keeps a simple log of review comments and how each was resolved. Each reviewer signs the log entry when a comment is resolved.

25.3 Presenting

The team presents to Ruth and two visiting practitioners. They explain their design and the trade-offs, such as choosing a simpler courier app sign-in to keep deliveries fast while limiting what the app shows. A practitioner asks how they would handle a courier's stolen phone; the team answers with their remote wipe and session expiry design. Ruth's feedback praises the review log, which shows how the design improved. Team studios teach that security designs are stronger when built and challenged by several people.

Worked example

Tomás's team designs security for a pharmacy delivery service with leads and peer review, fixing a zone error and adding a privacy scenario.

Synthetic case. The pharmacy service and team are synthetic.

Errors and limits

Teams can defer to the loudest member. Three weeks limits depth.

Exercises

EX073 — Zone error. What did Tomás find in the zone diagram? Rubric: 3 = couriers' phones in the same zone as warehouse systems;; 2 = zone;; 1 = vague;; 0 = none.
EX074 — Privacy addition. What scenario did the privacy student add? Rubric: 3 = prescription details visible on courier screens;; 2 = prescriptions;; 1 = vague;; 0 = none.
EX075 — Review log value. Why did Ruth praise the review log? Rubric: 3 = it showed how the design improved;; 2 = improvement;; 1 = length;; 0 = none.

Synthesis

Team studios with clear leads and mutual review produce stronger security designs than individuals working alone.

Continue studying — chapter 25 of 30

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