◇ OpenCyber Academy
Technologist · Chapter 25 · English

Chapter 25 — Team project studio

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 brief"]
  N2["25.2 Mei's team"]
  N3["25.3 Design"]
  N4["25.4 Critique"]
  N5["25.5 Integration"]
  N6["25.6 Teamwork"]
  N7["25.7 Presentation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 The brief"]
  N2["25.2 Mei's team"]
  N3["25.3 Design"]
  N4["25.4 Critique"]
  N5["25.5 Integration"]
  N6["25.6 Teamwork"]
  N7["25.7 Presentation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 The brief]
    |
    v
[25.2 Mei's team]
    |
    v
[25.3 Design]
    |
    v
[25.4 Critique]
    |
    v
[25.5 Integration]
    |
    v
[25.6 Teamwork]
    |
    v
[25.7 Presentation]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) work in a team to design a SOC improvement; (2) divide roles and integrate work; (3) present a design for critique; (4) incorporate feedback.

25.1 The brief

Teams of three design an onboarding package that brings a new small client to "monitored and verified" within two weeks.

Two weeks is a target the team must justify step by step, because onboarding has many dependencies on the client. "Monitored and verified" means more than agents installed; it means every data flow on the diagram has been shown to deliver test events, as Mei did when she found the misdirected firewall syslog in chapter 12. The brief also asks for evidence that each step happened, which is where Mei's verification work becomes central to the team's design.

25.2 Mei's team

Mei, a networking student and a programming student divide the work: data flows and verification (Mei), firewall and VPN checks (networking), and automation of the onboarding checklist (programming).

The split follows each student's training, and each part touches the others: Mei's verification needs the networking student's firewall checks, and the programming student's checklist records both. Mei takes data flows because she has already found a real fault in one, and verification is where most onboarding problems appear. Each student owns one part but reviews the others, so a misunderstanding about how the parts connect is caught before the pilot.

25.3 Design

Day 1–2: agreement and contacts; day 3–5: agents and syslog; day 6–8: verification with test events per data flow; day 9–10: baseline collection; day 11–14: rule enablement and first report.

The order of the blocks follows the dependencies between the onboarding steps. Contacts and an agreement come first because nothing may be installed without them; verification comes before baselines because a baseline from a broken feed would be wrong; and rules are enabled last because they need both the data and the baseline. Each block of days also has a named owner within the team of three. Days 6 to 8 are Mei's verification block, which gives three days to find and fix faults like the misdirected syslog before baselines start.

25.4 Critique

Raj and a client account manager critique the design. The account manager notes clients rarely respond within a day; the team adds a reminder step and a "waiting on client" status so delays are visible.

The critique changed the plan rather than only the slides. A day's wait on the client at each of several steps could stretch two weeks to three. With the reminder step and the new status, the account manager sees which client step is overdue and can chase it, and the team's own work is not blamed for the delay.

25.5 Integration

The automated checklist marks each step done only when evidence is attached, such as a screenshot of test events arriving.

Requiring evidence closes the gap between "configured" and "working" that caused the missing firewall logs in chapter 12. A step marked done without a screenshot or a SIEM search result simply stays open, so the checklist cannot report a client as monitored while one of its feeds is still pointing to an old address. The evidence attached at each step also becomes part of the client's record, so later analysts can see when each feed was first verified.

25.6 Teamwork

Weekly stand-ups and a shared board keep the three parts aligned.

Stand-ups surfaced the dependency problems early, for instance when the checklist needed a field for evidence from the networking student's VPN checks that had not been planned. A shared board showed each part's open items, so the three students could see when one part was blocking another rather than discovering it at integration. The board also held the waiting-on-client items, so the team could see which delays came from the client and which from their own work. Each stand-up ended with a named person for every blocked item, which kept small problems from waiting a week.

25.7 Presentation

The final presentation shows the two-week plan, evidence requirements and the dashboard.

The audience is Raj and the account manager, so the presentation leads with the plan a client would follow and the evidence each step produces. The dashboard shows how a client's onboarding status would appear, including the waiting-on-client status added after the critique, which addresses the account manager's main concern. The team also shows the pilot plan with the veterinary practice, so the audience can judge the design against a real client rather than a slide. Questions from Raj and the account manager focus on the waiting-on-client status and on how the checklist proves each data flow.

Documentation

The package includes a client-facing one-page guide explaining what will happen each day, what the client must do, and who to call. The account manager reports that clients appreciated knowing the plan in advance.

Lessons for the team

The team notes that integrating three parts took longer than building each, and plans integration time from the start next time.

Worked example

The team pilots the package with a real new client, a veterinary practice. Monitoring is verified on day 12; the only delay was waiting for the client to approve the firewall change, which the "waiting on client" status made visible to the account manager.

Synthetic case. The studio and client are invented.

Errors and limits

Pilots with one client show feasibility, not typical timing.

Exercises

Synthesis

Team studios turn separate skills into an integrated, critiqued design tested in a pilot.

Continue studying — chapter 25 of 30

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