Design a Safe Lab Lifecycle

A safe cyber lab is more than a virtual machine that turns on.

It is a controlled sequence with a beginning, a boundary, evidence rules, and a known ending.

The most common classroom failure is not an advanced exploit escaping a VM. It is simpler:

• students do not know which system is in scope
• evidence is saved in the wrong place
• a VM starts from the wrong state
• an exercise unexpectedly has more network access than needed
• a reset destroys the student's work
• real information gets mixed into synthetic lab data

A good lifecycle prevents those failures before the technical exercise begins.

The six-stage lifecycle

Use this model:

prepare → verify → execute → observe → preserve → reset

Prepare

Confirm the approved environment, objective, and required files.

Verify

Check user, hostname, network boundary, snapshot state, and evidence location.

Execute

Perform only the actions required by the lab.

Observe

Capture the outputs that answer the lab question.

Preserve

Save the minimum evidence needed for the report.

Reset

Return the environment to the required known-good state or leave it preserved if the teacher instructs you to do so.

Preflight checks

Before a lab, build a preflight record.

Suggested commands inside a Linux guest may include teacher-approved checks such as:

whoami
hostname
pwd
ip addr

The exact commands depend on the environment.

The goal is to answer:

• Which user am I?
• Which guest system am I using?
• Where am I in the filesystem?
• What network interfaces are visible?

Do not copy an IP address and assume it is safe to target. The preflight record describes the environment. Authorization still comes from the lab instructions.

Build a lab manifest

For a fictional course VM, create this manifest:

A stop condition tells you when not to improvise.

Examples:

• unexpected external network access appears
• the VM displays a real person's information
• the supplied target is unavailable
• the lab requires a command not described in the approved workflow
• the VM is not in the expected snapshot state

Stopping is not failing the lab. It is evidence that the control boundary is working.

Snapshot reasoning

Suppose the expected starting snapshot is gsc-week05-clean, but the VM opens with files from another class already present.

What should you do?

Do not delete the files and keep going.

The environment has failed the preflight check.

Record the mismatch and restore or request the correct state.

Why?

Because the previous state can affect your results and may contain data outside your authorization boundary.

Evidence handling

A lab report does not need every byte the system produced.

Capture evidence that supports the learning objective.

If the question is whether a permission blocks access, useful evidence might be:

• the permission setting
• the attempted approved action
• the resulting denial

You probably do not need a complete disk image.

Use the principle:

Collect enough to support the claim, not everything you can reach.

Lab failure scenarios

Analyze these situations.

Scenario 1: wrong snapshot

The expected clean snapshot is missing.

Scenario 2: extra connectivity

The lab should be private, but the guest can reach a public website.

Scenario 3: evidence path missing

The instructions say to save output to /home/student/evidence, but the directory does not exist.

Scenario 4: real information appears

A log contains a real student's email address instead of synthetic data.

Scenario 5: task complete, VM still altered

The student finishes the lab but leaves the VM in a modified state for the next person.

For each scenario:

1. identify the risk
2. identify the lifecycle stage that should catch it
3. state the correct response
4. state what evidence should be recorded

Reproducibility test

A strong lab procedure should allow another student to reproduce the result.

Write a short procedure for this harmless task:

In the supplied VM, locate system-status.txt, record its file permissions, read the first five lines, and save a short observation in the approved evidence folder.

Your procedure must include:

• starting state
• commands or actions
• expected evidence
• failure condition
• reset or finish step

Then exchange procedures with another student and identify one ambiguous instruction.

Rewrite it.

Minimal privilege

Do not use administrator or root privileges just because a command works more easily that way.

If the exercise can be completed as the normal student account, stay there.

Higher privilege increases the amount of the system you can change and the impact of a mistake.

Use privilege because the task requires it and the exercise authorizes it, not because it is convenient.

Evidence for Lesson 2

Submit:

• completed lab manifest
• five failure-scenario analyses
• reproducible system-status procedure
• one revised ambiguous instruction from peer review

Finish with:

The preflight check I would never skip is ________ because ________.

A reliable lab begins before the interesting command. If the environment is not controlled, the result is harder to trust.