VM Lab: Observe, Break the Assumption, Recover

A safe lab should let you test an idea without needing a real target.

This exercise uses a teacher-provided virtual machine or embedded simulation to practice three professional habits:

1. verify the environment
2. test only the approved condition
3. recover to a known state

The point is not to "break the VM." The point is to observe how system state changes and prove that you can return the environment to a trusted baseline.

Scenario

The lab VM contains a fictional application configuration:

/home/student/app/config.txt

The approved file begins with:

mode=training
logging=enabled
max_attempts=5

A second file contains synthetic application events:

/home/student/app/events.log

Your task is to document the baseline, make one authorized change, observe the result, and then restore the original state.

Phase 1: preflight

Record:

whoami
hostname
pwd

Then confirm that the expected files exist.

Do not proceed if:

• the hostname is not the expected lab guest
• the files contain real personal information
• the starting configuration does not match the teacher-provided baseline
• the environment has unexpected external connectivity when the lab should be isolated

Phase 2: preserve the baseline

Before changing anything, record:

• file path
• file permissions
• original three configuration lines
• timestamp shown by the lab environment

If the platform supports a teacher-managed snapshot or reset point, confirm the expected checkpoint.

The baseline is your evidence of trusted state.

Phase 3: make one authorized change

The lab authorizes this change only:

max_attempts=5

to:

max_attempts=3

Use the method provided by the teacher or embedded lab.

Do not change mode or logging.

Why such a small change?

Because controlled experiments are easier to reason about when only one variable changes.

Phase 4: observe the effect

The simulation provides new synthetic events after the configuration change.

Compare the before and after output.

Create a table:

Add at least two observations from the supplied event output.

Do not claim that the new configuration is universally "more secure." It may reduce repeated attempts, but it can also increase accidental lockouts. Security controls have usability and availability trade-offs.

Phase 5: break the assumption

Your original assumption may have been:

Lowering the number of allowed attempts is always better.

Now challenge it.

Consider:

• users mistype passwords
• automated classroom tools may reconnect with old credentials
• account lockouts can reduce availability
• support workload can increase

Write a revised claim that includes both the defensive benefit and the trade-off.

Example structure:

Reducing attempts from five to three can make repeated online guessing harder, but the change may also increase legitimate lockouts. The right value depends on the surrounding monitoring, recovery, and user environment.

Phase 6: recover

Restore the approved baseline:

max_attempts=5

Then verify all three configuration values.

Do not assume the reset worked because the interface said "done."

Verification is part of recovery.

Build the lab record

Your final record must include:

Preflight

User, host, working directory, expected state.

Baseline

Original configuration and evidence.

Authorized change

Exactly what was modified.

Observation

Before/after evidence.

Trade-off

How the change affects security and usability or availability.

Recovery

How you restored and verified the baseline.

Limitation

What this small simulation does not prove about a real production system.

Isolation review

After the technical task, return to the virtualization diagram from Lesson 1.

Answer:

• Why did this exercise not require a real external account?
• Why did it not require a public network target?
• Which evidence could be safely exported?
• Which guest state should be discarded or reset?

This is the reason virtual labs matter. They let you learn the mechanism without borrowing risk from somebody else's system.

Evidence for Lesson 3

Submit:

• complete lab record
• before/after observation table
• revised security claim with trade-off
• recovery verification
• isolation review

Finish with:

I know the lab is complete only when ________.

A good cybersecurity lab does not end when the interesting behavior happens. It ends when the result is documented and the environment is back under control.