01 / Scope & evidence
Small scenarios. Checkable results.
These exercises were prepared as guided learning materials for this portfolio. The scenarios, identities and datasets are fictional, and their generation is reproducible.
The source download includes a worked example, a practice route and verification commands for each lab. No university assessment questions, submissions or recordings are included.
The exercise materials have passed automated reference checks. Jeremy's independent completion and explanation of unfamiliar variants remain to be assessed. Reference results describe the exercises; they are not a claim of production experience or independent authorship of every utility.
The first 26 exercises use offline evidence. The four hands-on labs add local traffic capture, a loopback-only training application, offline detection and a Windows lab VM. Start with one topic and use small commands, evidence tables and simple policy edits. Developing the supporting Python utilities is not part of the learner's task.
The additional twenty labs cover network investigation and testing, defensive operations and recovery, and cloud, identity and configuration. Each has a distinct question, three scenarios and a useful written deliverable.
No exercise targets an external system or changes real cloud permissions. The access-control training application uses fictional records and binds only to loopback. The Windows collection workflow is for a disposable VM; its supplied XML practice can be inspected offline.
02 / Network investigation
A name lookup did not work. What does the capture show?
Two fictional workstations make DNS requests in a generated packet capture. Some receive successful answers, some receive a name-not-found response, and some have no matching response in the captured interval.
The task is to match requests to responses, distinguish those outcomes and support each finding with packet evidence. A missing response is an observation; the capture alone cannot establish whether a server, a network path or the capture itself caused it.
What the exercise develops
- Using Wireshark display filters and reading DNS fields.
- Matching transactions and checking timing.
- Writing a short finding without overstating its cause.
The PCAP contains generated Ethernet, IPv4, UDP and DNS records. It is synthetic training data, not traffic captured from a real incident. The included verifier checks its structure and expected relationships.
Read the DNS lab instructions ↗
Protocol reference: Wireshark DNS display fields ↗
03 / Security operations
Several failed logins. One successful login. What next?
A fictional login-event dataset contains clustered failures, ordinary typing mistakes and service-account problems. A small training detector highlights patterns using an adjustable threshold and time window.
The analyst's job is to reconstruct the timeline, read the surrounding context and decide what further checks an escalation should request. A threshold match can justify investigation; it does not prove account compromise.
What the exercise develops
- Grouping events by identity and source.
- Understanding thresholds, time windows and false positives.
- Writing a concise handover that separates facts from hypotheses.
The log format and events are synthetic. The detector is a teaching heuristic, not a production SIEM or a validated incident verdict. The reference tests exercise timing and input-handling behaviour.
04 / Cloud-security foundations
Keep the access people need. Remove the rest.
A fictional storage service gives roles permission to read, write or delete objects. The exercise starts with broader access than the business requirements justify.
The task is to compare every allowed action with the requirements, revise an editable policy and check that necessary access still works. Simply denying everything would fail the business requirements.
What the exercise develops
- Separating identity verification from permission decisions.
- Applying least privilege to specific actions and resources.
- Testing both unwanted access and legitimate work after a change.
This is a deliberately small offline permission model. It is not an AWS or Azure IAM evaluator and does not claim a cloud deployment. It introduces access-review reasoning before adding provider-specific policy complexity.
05 / Web investigation
An unusual request. What happened after it?
A fictional web service records request methods, paths, source addresses and response codes. The exercise compares ordinary activity with patterns that deserve further investigation.
Build a short timeline, check the context and explain what the log does and does not show. A successful HTTP response does not by itself establish that an attempted attack worked.
What the exercise develops
- Reading web-log fields and grouping related requests.
- Distinguishing observations from assumptions about the application.
- Requesting useful follow-up evidence when logs are incomplete.
The requests and context are invented. This lab analyses saved records; it does not send requests to a target or run exploits. The triage rules are small teaching heuristics.
06 / Change investigation
The files changed. Was that the intended change?
A small set of dummy files has a recorded baseline and fictional change approvals. Compare the current files with the baseline, then separate expected edits from changes that need investigation.
Find added, removed and modified files. Explain how confidence in the baseline affects the conclusion, even when the comparison itself is correct.
What the exercise develops
- Using hashes to compare file contents.
- Checking changes against specific approval evidence.
- Recognising the limits of integrity checks and baseline trust.
A different hash shows different bytes; it does not prove malicious intent. A matching hash does not establish that a file is safe. All changes happen in a generated practice folder.
07 / Network boundaries
Which rule actually decides this packet?
An offline rule model compares fictional packets with an ordered policy. Read the source, destination, protocol and ports, then find the first matching rule.
Repair overly broad access and check that required traffic is still permitted. Changed scenarios introduce rule order, missing access and the difference between TCP and UDP.
What the exercise develops
- Tracing a packet through rules in order.
- Understanding default deny and rules that never get a chance to apply.
- Testing both blocked traffic and necessary access after a change.
This simulator decides one packet at a time. An allow result does not prove that a complete connection will succeed. It does not edit the computer's firewall and is not an evaluator for a real firewall product or cloud security group.
08 / Practice progression
Repeat the reasoning, then change the problem.
- Guided attempt: follow the worked example and explain each result.
- Prompted attempt: use a short checklist with the full answer hidden.
- Independent attempt: reset the exercise and complete it without step-by-step instructions.
- New variant: change the dataset and explain why the answer changes.
- Teach it back: give a short verbal handover, including what the evidence cannot establish.
Completion requires a correct explanation and a successful unfamiliar variant. Running a verification command or memorising one sequence does not establish that understanding. Personal practice evidence will be added after those steps have been completed.
A small session, then a later check
Start by recalling one idea, predict what a check should show, perform one task and explain the evidence. Record the help used and one thing to revisit. Aim for understanding; using notes and command help is normal.
Return on another day and again roughly a week later with a changed case. If something is unclear, practise that part before moving on. The guide includes topic prompts, common mistakes, a handover template and a blank private practice record.