Lesson 4: Security, Recovery, and Verification

Harborview's systems are working again.

That does not mean the capstone is finished.

Now you challenge the final state.

A workstation can open the application while the user has too much privilege. A guest network can reach the internet while also reaching staff systems. A backup job can report success while nobody has ever restored a file. A managed phone can synchronize while encryption is disabled.

Functional success and controlled success are different things.

Verification asks whether the requirement survived the repair

Return to the client requirements:

• productivity works;
• video meetings work;
• printing/scanning works;
• wired and wireless networking work;
• standard-user daily access remains standard;
• MFA remains enabled;
• endpoint protection/firewall remain enabled;
• data protection and recovery remain intact;
• changes are documented;
• privacy is preserved.

Every one of those becomes a test.

Verify least privilege instead of assuming it

Check the daily account model on Harborview endpoints.

For a workstation:

daily user → standard operations: allowed
daily user → administrative change: denied or requires approved elevation

The second result matters.

If the user can silently install drivers, disable security controls, or change system-wide configuration without the approved elevation path, the requirement is not met.

Security verification includes expected failure.

Verify MFA by testing the normal path, not by removing it

For staff/cloud accounts:

• normal sign-in succeeds;
• required MFA challenge occurs under policy;
• the user can complete the approved factor;
• recovery method is documented under the fictional environment;
• unexpected prompts remain something the user should deny and report.

If an earlier incident involved unexpected MFA prompts, confirm the account-security response did not weaken the control afterward.

The fix should leave the environment safer, not merely quieter.

Verify endpoint protection state

For each required endpoint, confirm the supplied state shows:

• endpoint protection enabled;
• definitions/security intelligence current where applicable;
• firewall enabled for the required profile;
• no broad unnecessary exception introduced during troubleshooting;
• required application paths still work.

If you created a firewall exception, verify both:

required service: works
unrelated prohibited path: still blocked where the scenario requires it

A firewall rule should be narrow enough to explain.

Verify update and support state

Check:

• operating system support/lifecycle;
• required OS updates;
• application updates;
• mobile OS/app patch state;
• router/AP firmware state;
• printer firmware if included in the supplied configuration;
• VM guest/support state.

Do not write fully patched unless the supplied evidence supports it.

A strong record says what was verified and what was not.

Verify wireless security and separation

The staff/mobile wireless path should satisfy the required security configuration.

If Harborview includes guest access, test both the allowed and denied paths.

Example:

guest client → internet: allowed
guest client → staff workstation: denied
guest client → printer management: denied if not required

A guest network that reaches everything is connected.

It is not separated.

Also confirm:

• approved wireless security mode;
• management access is protected;
• no unexplained legacy compatibility mode is enabled;
• AP/router firmware is supported;
• unnecessary remote management or port forwarding is absent.

Verify the printer as both an output and data system

Test the print path:

workstation
→ correct queue
→ printer reachable
→ correct page output

Then test the scan path separately:

ADF / flatbed
→ MFP
→ approved destination
→ file arrives
→ authorized user can access it

If privacy is part of the staff workflow, verify the output/release behavior the scenario requires.

Do not call the MFP healthy because one internal test page printed.

Verify mobile management after the sync repair

If the seeded incident involved mobile policy, confirm the final state includes:

• MDM enrollment remains intact;
• required synchronization works;
• screen-lock policy remains compliant;
• device encryption remains enabled;
• OS/app patch state is acceptable;
• approved Wi-Fi profile works;
• remote backup/management capabilities remain in the intended state.

A local workaround that removed management is not an acceptable repair.

Verify the practice VM against its actual network requirement

If external access was required for the approved exercise, verify it.

Then verify the boundaries that should still remain.

For example:

VM → approved external repository/service: allowed
VM → restricted management network: denied/not routed

The exact paths depend on the supplied scenario.

The important point is that one successful internet request does not prove the virtual network is correctly bounded.

Also check:

• host resources remain healthy;
• virtual disk has adequate free space;
• snapshot role is documented;
• independent recovery exists where required.

Recovery must be demonstrated

Harborview's backup requirement is not complete until at least one restore path is tested.

Use a supplied non-sensitive test file or fictional dataset.

A safe restore test can look like:

identify backup version
→ choose alternate restore location
→ restore file
→ verify file opens / content matches expected state
→ record result
→ remove test copy under procedure if appropriate

Do not overwrite the live file merely because you are testing recovery.

The restore test should reduce risk, not create it.

Test deletion recovery separately from device failure recovery

Cloud synchronization can protect availability across devices while still propagating an unwanted deletion.

Ask two different questions:

1. Can Harborview restore a file deleted accidentally?
2. Can Harborview recover required data after a workstation drive fails?

The same mechanism may not answer both.

Version history, cloud retention, endpoint backup, and independent backups have different failure coverage.

Do not write cloud = backed up.

Name the recovery mechanism.

Verify data handling and ticket privacy

Review the support record itself.

Remove or reject unnecessary sensitive content.

A ticket should not contain:

• passwords;
• MFA codes;
• full confidential documents;
• unrelated personal files;
• copied private messages;
• sensitive data pasted into an unapproved AI tool.

The record needs enough evidence to explain the incident.

It does not need every fact the technician encountered.

Verify change history and rollback evidence

For every significant capstone change, confirm the record includes:

baseline
reason
scope
approval
change
rollback/recovery
verification
result

If an update was rolled back, document both states:

• why the update was attempted;
• why the final state returned to the previous version;
• what requirement remains unresolved.

A rollback should not erase the history that caused it.

Security review is also about things you did not change

Some controls should remain untouched because they were already correct.

Examples:

• endpoint protection already current;
• firewall already configured correctly;
• MFA already enabled;
• disk encryption already healthy;
• printer privacy configuration already acceptable.

Do not toggle a control off and back on just to prove you interacted with it.

Verification is evidence gathering, not performance theater.

Worked verification: corrected DNS incident

The DNS incident was repaired.

A weak closeout says:

DNS fixed.

A stronger verification chain says:

client IP/gateway: unchanged and valid
DNS query: returns expected portal address
portal by hostname: opens
staff login: succeeds
required portal function: works

What remains outside that proof?

• every other DNS record;
• every remote service;
• long-term reason the DNS configuration became wrong.

Keep the claim bounded.

Worked verification: memory incident

The original memory configuration restored POST.

What does that prove?

It strongly connects the failure to the changed memory path.

What does it not yet prove?

That the new module itself is defective.

It may be:

• incompatible;
• installed in the wrong slot;
• poorly seated;
• faulty.

The final service record should say what the evidence supports, not the most dramatic conclusion.

Unresolved risk is a legitimate final state

Some problems cannot be fully resolved locally.

Examples:

• provider outage;
• unsupported legacy hardware;
• vendor application incompatibility;
• required policy change owned by another administrator;
• hardware awaiting warranty replacement;
• account-security investigation owned by the security team.

Do not hide unresolved risk because the capstone wants a clean ending.

A professional handoff says:

what remains unresolved
current impact
temporary workaround if approved
risk
owner/escalation path
next expected action

Knowing where your authority ends is part of technical competence.

Build the final verification record

Functional checks

all six workstations boot:
productivity/browser functions:
video meeting camera/mic:
wired connectivity:
staff/mobile Wi-Fi:
DNS / cloud access:
printing:
scanning:
VM required function:

Security checks

standard daily accounts:
admin elevation path:
MFA:
endpoint protection:
firewall:
disk/device encryption:
wireless security:
guest separation if applicable:
mobile MDM/lock:

Recovery checks

backup state:
restore test:
deleted-file recovery path:
application/config rollback:
VM recovery:

Operations checks

change records complete:
tickets privacy-safe:
asset state updated:
unresolved risks documented:
escalation owners assigned:

Before you move on

A final system state should be able to survive one question:

Show me the evidence.

Not:

Trust me, I configured it.

Lesson 5 is the handoff. You will turn that evidence into a service record another technician can use and a client explanation Harborview can understand.