Chapter 25 — Laboratory I
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 Lab environment"]
N2["25.2 Tasks"]
N3["25.3 Findings expected"]
N4["25.4 Report"]
N5["25.5 Assessment"]
N6["25.6 Safety"]
N7["25.7 Debrief"]
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 Lab environment"]
N2["25.2 Tasks"]
N3["25.3 Findings expected"]
N4["25.4 Report"]
N5["25.5 Assessment"]
N6["25.6 Safety"]
N7["25.7 Debrief"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 Lab environment]
|
v
[25.2 Tasks]
|
v
[25.3 Findings expected]
|
v
[25.4 Report]
|
v
[25.5 Assessment]
|
v
[25.6 Safety]
|
v
[25.7 Debrief]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) practise configuration review on a synthetic environment; (2) apply registry, identity and logging checks together; (3) write a short lab report.
25.1 Lab environment
A synthetic export set models a small university platform: three accounts, a registry, a cluster and identities. No real systems are involved.
The synthetic platform resembles StudyHub closely enough that the lessons transfer, but every name, setting and identity is invented. Students cannot accidentally touch a real system, and the lab can be shared freely between cohorts. The export files are the same format as real cloud exports, so the scripts work unchanged. Each pair receives the same files, so results can be compared.
25.2 Tasks
Run the registry review, the account review and the logging coverage check; build the role graph; list findings by severity.
The tasks reuse scripts from earlier chapters on new data, which tests whether students understood the methods rather than memorised the original results. Building the role graph from the lab's identities may produce a different path from the one in the discrete structures chapter, which is part of the exercise. Pairs decide the order in which to run the checks, and record it in their log. Most start with the registry, since it echoes the opening case, but the instructions do not require any particular order.
25.3 Findings expected
Students should find an anonymous repository, an account without MFA, missing logging in one region and a role path from a support account to an admin role.
Each expected finding corresponds to one of the course's main lessons: registry exposure, identity hygiene, logging coverage and privilege paths. A report missing one suggests a check was not run or its output was misread. Finding extra issues earns credit if they are supported by evidence. Dr Jensen's marking guide lists the expected findings with the evidence that supports each, so marking is consistent between pairs.
25.4 Report
One page: summary, findings with evidence, recommended fixes and order.
One page forces choices: each finding gets a sentence of evidence and a sentence of action, and the order shows priority. The format mirrors what Tom expects from Samuel in the real project, where managers will not read long reports. Samuel's pair wrote theirs as a numbered list with four findings, each giving the resource, the evidence line from the export, the risk in one sentence and the fix in one sentence. A short paragraph at the top stated the assumptions behind their ranking, such as treating outside attackers and insiders as equally likely.
25.5 Assessment
Completeness, accuracy, prioritisation and clarity.
Accuracy means each finding is correct and supported; completeness means the expected findings are present; prioritisation means the order is justified; clarity means a non-specialist could act on it. Each counts for a share of the mark, so a long report with poor ordering does not score well. Feedback names the strongest and weakest of the four for each pair. In Samuel's cohort, accuracy was generally high and prioritisation the weakest, because many pairs ranked findings without explaining why. The debrief addresses that directly, using anonymised examples from the reports.
25.6 Safety
All data synthetic; scripts read files only.
Scripts that only read files cannot change anything, even if run against the wrong directory by mistake. Students are told to keep the lab files separate from any real exports they might have access to through work, so data from the two never mix in a report. The scripts were reviewed by Dr Jensen before the lab to confirm they contain no network calls or write operations. Students may not add any, and their logs of commands run would show it if they did. This keeps the lab safe even if a student's laptop has real credentials configured for other work.
25.7 Debrief
Students compare reports and discuss differences in prioritisation.
Differences usually come from assumptions: one pair might weight outside attackers highest, another insider misuse. Discussing them shows that priorities depend on threat models, and that stating assumptions is what makes a ranking defensible. Samuel's pair ranked the support-to-admin path first because of its impact, while another pair ranked the anonymous repository first because outsiders could exploit it with no effort. Both reasons were sound, and the discussion settled on fixing both together. Dr Jensen used the exchange to show that a ranking is only as good as the assumptions written beside it.
Lab preparation
Before the lab, students review the scripts from earlier chapters and read the synthetic environment description. Dr Jensen provides a short guide on how findings will be assessed, including that a clear statement of assumptions earns credit even when rankings differ. Students work in pairs, which mirrors real practice where reviews are checked by a second person. Each pair keeps a log of commands run and files read, which is submitted with the report as evidence of method.
After the lab
Feedback is returned within a week with comments on evidence, ranking reasons and clarity, and each pair revises one section.
Marks
Marks are shared with each pair.
Worked example
Samuel's report ranks the support-to-admin path first, ahead of the anonymous repository, because it could give someone full control. Dr Jensen accepts the reasoning but notes that the anonymous repository is easier to exploit by outsiders; the debrief agrees both belong at the top, fixed in parallel.
Synthetic case. The lab is synthetic.
Errors and limits
Ranking depends on assumptions; state them.
Exercises
- EX073 — Lab tasks. List the lab tasks. Rubric: 3 = registry, accounts, logging, role graph; 2 = three; 1 = one; 0 = none.
- EX074 — Expected findings. Name two expected findings. Rubric: 3 = anonymous repo, no-MFA account, missing log region, support-admin path; 2 = one; 1 = vague; 0 = none.
- EX075 — Ranking debate. How was the ranking debate resolved? Rubric: 3 = both top, fixed in parallel; 2 = partial; 1 = vague; 0 = none.
Synthesis
Combine checks and justify priorities.
Continue studying — chapter 25 of 40
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →