Hardening Review: Turn Findings Into Evidence

A hardening project is complete only when the recommended state is verified.

This lesson combines the CVE reasoning from Lesson 1 with the configuration baseline from Lesson 2.

You will perform a classroom-safe hardening review of a fictional workstation profile.

No real school system is being scanned or changed.

Concept flow

A CVE is useful only when you connect it to your actual system

Defensive vulnerability work moves from inventory to applicability, priority, controlled change, and verification.

1. INVENTORYproduct, version, configuration, exposure
   compare with
2. CVE RECORDaffected versions, weakness, impact, references
   decide
3. APPLICABILITYis this fictional system actually affected?
   prioritize
4. HARDENupdate, configure, remove exposure, back up, or reduce privilege
   prove
5. VERIFYrescan or compare before/after evidence

Use the flow as the order of operations for the lab. A CVE record matters only after you establish whether it applies to the system you are actually reviewing, and a configuration change is not complete until the new state is verified.

The workstation profile

Your teacher provides a synthetic system report containing:

• operating-system version
• installed application versions
• user accounts
• privilege levels
• firewall state
• update state
• screen-lock policy
• backup state
• enabled services
• selected vulnerability records

Your job is to decide what matters first.

Step 1: inventory before recommendations

Create an asset/configuration inventory.

A recommendation without a known current state is weak.

Step 2: separate vulnerability findings from configuration findings

A CVE may indicate a vulnerable software version.

A hardening benchmark may indicate a risky configuration.

Those are related but different.

Example:

• vulnerability finding: browser version falls inside an affected range
• configuration finding: guest account is enabled

The response should match the finding.

Step 3: prioritize

Use three dimensions:

• impact if the weakness is exploited or fails
• exposure in the fictional environment
• effort/side effect of the change

Then place findings into:

• fix first
• schedule soon
• monitor/review

Do not make every finding critical.

Prioritization is part of the work.

Step 4: create the change plan

For each top finding, document:

Current state

What evidence shows the problem?

Desired state

What should change?

Reason

Which threat or CIA property does the change address?

Side effect

What legitimate use could be affected?

Rollback

How would the approved system return to the earlier state if the change causes a problem?

Verification

What evidence would prove the new state?

Step 5: simulate the change

The lab provides before/after configuration records.

Compare them.

Do not simply mark "fixed."

Verify each item.

Example:

Before: guest_account = enabled
After:  guest_account = disabled

If the goal was to disable the guest account, the after-state supports the claim.

Step 6: rescan

A synthetic second assessment report shows which findings remain.

Classify each result:

• remediated
• unchanged
• new finding
• needs manual review

If a new finding appears after hardening, investigate the change instead of hiding the result.

Backup and recovery test

The workstation profile also includes a backup record.

A backup exists from yesterday.

Is that enough evidence that recovery works?

No.

The lab provides a synthetic restore test showing whether a sample file can be recovered.

Record:

• backup date
• restore test result
• what data was restored
• what the test does not prove

Build the final hardening report

Your report should have five sections.

Executive summary

Three to five sentences describing the largest risks and the overall state.

Findings table

For each finding:

• evidence
• risk
• recommendation
• priority

Change evidence

Show the before/after state for the approved simulated changes.

Verification

Explain how you confirmed remediation.

Remaining risk

Name at least two issues that are not fully solved.

Optional CyberPatriot connection

If the teacher uses a CyberPatriot-style demonstration image, compare the workflow:

inspect → score/finding → change → verify

Do not chase points blindly. Explain why each configuration change is defensible.

Evidence for Lesson 3

Submit:

• asset/configuration inventory
• prioritized finding list
• change plan
• before/after verification
• backup restore analysis
• final hardening report

Finish with:

A hardening score is useful only when I can explain ________.

The goal is not a green dashboard. The goal is a system state you can defend with evidence.