Competition Strategy 07
Make defensive changes because the evidence supports them, not because a checklist says every system should look the same.
Evidence-based hardening combines scenario requirements, system observations, security policy, forensic context, and verification into one decision-making process.
Lesson Snapshot
Learning objectives
Explain what evidence-based hardening means and why it is safer than blindly following a checklist.
Use scenario, system, policy, and forensic evidence to justify defensive decisions.
Separate observation, interpretation, action, and verification so assumptions do not become facts.
Recognize when a security recommendation should be adapted because of required functionality.
Choose the least disruptive change that still addresses the confirmed problem.
Verify both the improved security state and the continued operation of required services after major changes.
Core concept
Secure configuration is not just a list of settings. The team must understand what the system is supposed to do, what is currently true, what is actually wrong, and what change will improve security without creating a new problem.
Key rule
A checklist is useful for coverage. Evidence determines whether the setting on this image actually needs to change.
Four evidence types
The competition instructions define authorized users, administrators, services, applications, restrictions, or required capabilities.
Example
The scenario says only one named user should be an administrator. This gives you a clear reference for evaluating elevated privileges.
The machine itself shows a specific condition through users, groups, settings, services, files, logs, processes, software, or configuration.
Example
A user is currently in the local Administrators group even though the scenario does not authorize that privilege.
A security requirement or accepted defensive standard explains what a secure configuration should look like.
Example
A password or firewall policy provides a baseline for judging whether the current setting is too weak.
Logs, timestamps, files, metadata, processes, or other artifacts support an investigation or answer a forensic question.
Example
A log entry supports a conclusion about when a suspicious event happened and helps the team decide what should be preserved.
Reasoning chain
Record the actual condition without immediately labeling it malicious, safe, authorized, or unnecessary.
Compare the observation with scenario requirements, known policy expectations, and other available evidence.
Determine whether the condition is confirmed as a problem, still uncertain, or intentionally required.
Apply the least disruptive defensive action that addresses the confirmed issue while preserving required functionality.
Confirm the security condition improved and that the system still performs its required role.
Record the reason, change, result, and any remaining follow-up so the team can trace what happened.
Confidence levels
The scenario or strong system evidence clearly identifies a problem, and the team understands the likely impact of the fix.
Recommended response
Proceed with a controlled change and verification.
The condition looks suspicious or insecure, but some context is still missing.
Recommended response
Investigate further, coordinate with the team, and avoid disruptive action until the uncertainty is reduced.
The conclusion depends mostly on assumptions or unfamiliarity rather than evidence.
Recommended response
Do not make a high-impact change. Record the observation and gather evidence first.
Ask before acting
What exactly did I observe?
What evidence makes this a security problem?
Does the scenario require the affected user, service, software, or capability?
What is the least disruptive way to address the issue?
What side effects could this change create?
How will I verify both security and functionality afterward?
Does this action affect forensic evidence?
Should another teammate know before I make this change?
Checklist vs. evidence
A checklist can help you remember common areas to inspect: users, services, updates, firewall, software, permissions, logs, and policies.
The checklist tells you where to look. Evidence tells you whether a change is appropriate on this specific image.
Required functionality and explicit restrictions override generic advice that would otherwise remove or break something the system must provide.
The task is not complete until you confirm both the secure state and the continued operation of required functionality.
Least-disruptive change
Weak approach
Delete the user account immediately.
Better approach
If the user is authorized to exist but not authorized as an administrator, remove only the unnecessary elevated privilege and verify the account still works as intended.
Weak approach
Disable the service because reducing services is generally safer.
Better approach
Keep the required capability available and harden the service configuration, permissions, exposure, or access controls instead.
Weak approach
Delete the rule without checking what depends on it.
Better approach
Determine what traffic is required, narrow the rule if appropriate, and verify the required communication still succeeds.
Weak approach
Delete the file immediately.
Better approach
Preserve and inspect the evidence first, answer the forensic question using supported facts, then take the appropriate defensive action if the file is confirmed to be unsafe or unnecessary.
Verification
Confirm the setting, group membership, service state, policy, permission, or rule now matches the intended secure state.
Confirm the required application, service, login, network path, or user workflow still functions.
Confirm the original exposure or weakness is actually reduced rather than simply changed cosmetically.
Make sure the result is communicated and recorded so other teammates understand the new state.
Worked cases
Observation
The scenario lists Maya as the only authorized administrator. Jordan is a legitimate user but is currently in the Administrators group.
Evidence
Scenario evidence confirms Jordan is authorized to have an account but not authorized to have elevated privileges.
Decision
Correct the privilege mismatch rather than deleting the legitimate account.
Verification
Confirm Jordan remains a user, is no longer an administrator, and Maya retains the required administrative access.
Observation
A remote-management service is enabled and appears in a generic hardening guide as something that can increase attack surface.
Evidence
The scenario explicitly requires remote management for this system.
Decision
Keep the service available, then review its access controls, firewall exposure, authentication, and configuration instead of disabling it.
Verification
Confirm the service remains reachable only as required and that the hardened configuration still supports the scenario.
Observation
An unfamiliar application launches at startup.
Evidence
The scenario does not mention it, and the team has not yet confirmed whether it supports required functionality.
Decision
Place the item in Investigate rather than immediately removing it.
Verification
After identifying its purpose and dependencies, take the justified action and confirm no required function is lost.
Observation
A file looks suspicious and may relate to a question asking about recent activity.
Evidence
The forensic question makes the file potentially valuable evidence.
Decision
Inspect and document the evidence before deleting, moving, or altering it.
Verification
Confirm the forensic answer is supported, then complete any necessary cleanup while preserving required documentation.
Common mistakes
A recommendation should not be applied just because it is commonly labeled a best practice. Context matters.
Unfamiliar accounts, services, or programs are investigation targets, not automatic deletion targets.
When the action is high risk, gather stronger support from the scenario, system state, policy, or teammate review.
A successful command or saved setting does not prove the system is now secure or functional.
Changing a visible setting without understanding the underlying cause can leave the real issue unresolved.
High-impact changes should be approached in a way that makes troubleshooting or rollback possible if the assumption is wrong.
Reflection
Question 1
Why is an unfamiliar service not automatically evidence that the service should be disabled?
Question 2
What is the difference between a checklist item and evidence that justifies a change?
Question 3
Why should required functionality affect how a system is hardened?
Question 4
What makes a least-disruptive change safer than a broad change?
Question 5
Why should verification include both security and functionality?
Question 6
When should a team delay a change even if the configuration looks insecure?
Evidence-based checklist
State the observation without adding assumptions.
Identify scenario evidence that applies.
Identify system evidence that supports the concern.
Use policy evidence when it helps define the secure state.
Protect forensic evidence before cleanup or destructive changes.
Rate your confidence before acting.
Choose the least disruptive justified change.
Communicate high-impact actions before making them.
Verify the configuration after the change.
Verify required functionality still works.
Document the result and any remaining uncertainty.
Revisit the task if new evidence changes the conclusion.
Next strategy lesson
Next, learn how to harden services, roles, applications, and network functions that the scenario requires without breaking the system's mission.