Pass 1
Understand the story
Read from beginning to end without immediately trying to solve individual issues. Identify the organization, machine role, users, services, and overall mission.
Competition Strategy 02
Read the Scenario First
Turn the competition scenario into a set of technical constraints before you begin changing the system.
The scenario tells you what the machine is for, who belongs on it, what must keep working, and what evidence may matter. Reading it carefully is not paperwork before the real work. It is the first technical task.
Lesson Snapshot
Reading method3 passes
Extraction groups6
Main skillConstraint mapping
GoalKnow before changing
Core concept
The scenario defines the mission
Security is not simply the absence of services, accounts, or software. A defended system must still perform its authorized purpose. The scenario gives you the context needed to distinguish legitimate functionality from unnecessary risk.
That context should influence every later decision about users, permissions, services, applications, firewall rules, remote access, updates, and evidence handling.
Key distinction
Unknown does not automatically mean unauthorized
An unfamiliar user, program, service, or configuration deserves investigation. It does not automatically deserve removal. First compare it with the scenario, then gather enough system evidence to make a controlled decision.
When the scenario does not answer a question, label it as an unknown instead of filling the gap with an assumption.
Three-pass reading method
Read for understanding before reading for fixes
Re-reading is useful because each pass has a different purpose. The first builds context, the second extracts constraints, and the third protects evidence and prepares investigation.
Pass 2
Extract constraints
Read again and record authorized users, administrators, required software, required services, restrictions, exceptions, and anything that must remain functional.
Pass 3
Connect tasks to evidence
Review forensic questions and suspicious details. Decide what should be inspected before making changes that could alter useful evidence.
Constraint extraction
Six things to pull out of every scenario
These categories turn a paragraph of competition instructions into information the team can use while defending the image.
Extract 01
Mission and system purpose
Determine what the machine is supposed to do. A workstation, server, development machine, or system supporting a specific service may require different defensive decisions.
What role does this machine serve?
What functionality must remain available?
Are there special operational requirements?
Extract 02
Authorized users
Identify the accounts that are explicitly allowed to exist. Do not assume an unfamiliar account is unauthorized simply because you do not recognize it.
Which users are authorized?
Are any accounts explicitly prohibited?
Are there special account requirements?
Extract 03
Authorized administrators
Separate permission to use the system from permission to administer it. A legitimate user does not automatically need elevated privileges.
Who is allowed administrative access?
Which users should remain standard users?
Are group memberships described?
Extract 04
Required services and applications
Record software, roles, services, and capabilities that must remain operational. Generic hardening advice must not override an explicit competition requirement.
Which services must stay enabled?
Which applications are required?
What dependencies might support them?
Extract 05
Restrictions and exceptions
Look for wording that changes the normal approach. Exceptions are easy to overlook because they may appear as one sentence inside a larger scenario.
What must not be changed?
Are there unusual policy requirements?
Does the scenario create an exception to a common best practice?
Extract 06
Investigation clues
Notice references to suspicious activity, files, users, logs, incidents, or other evidence. These clues may connect directly to forensic questions.
What evidence may need preservation?
What claims need verification?
Which areas should be inspected before broad changes?
Language signals
Small words can create major technical constraints
Competition instructions often communicate importance through ordinary language. Train yourself to notice words that establish requirements, boundaries, and investigation clues.
must / required
Treat the item as a constraint that your defensive work must preserve unless later evidence clearly changes the interpretation.
authorized / approved
Use the scenario's definition when evaluating accounts, administrators, software, or access.
only
This often creates a boundary. For example, only named administrators may be intended to have elevated privileges.
should not / must not
Treat this as a warning against a change or condition that might otherwise seem reasonable.
needed for operations
Protect the associated functionality while investigating how to secure it.
recent / suspicious / reported
This may point toward evidence that should be examined before broad cleanup or configuration changes.
Shared notes
Build a one-page scenario map
The goal is not to rewrite the entire ReadMe. Create a compact reference that teammates can scan while they work.
System purpose
What is this machine expected to provide or support?
Authorized users
Who is allowed to have an account?
Authorized admins
Who is allowed elevated access?
Required services
What must remain running or available?
Required software
What applications or tools must remain installed?
Restrictions
What must not be changed, removed, or interrupted?
Forensics
What questions or evidence need investigation?
Unknowns
What details are unclear and need verification?
Facts vs. assumptions
Keep three mental buckets
Confirmed fact
The scenario or reliable system evidence directly supports the conclusion.
Unknown
The available information does not yet answer the question. Investigate before making a disruptive decision.
Assumption
A conclusion that feels plausible but is not yet supported. Treat it as a hypothesis, not as permission to change the system.
Good competition reasoning often sounds like: “We know X from the scenario. We observed Y on the system. Z is still unknown, so we will verify it before making the higher-risk change.”
Scenario vs. checklist
What if a normal hardening step conflicts with the mission?
The scenario provides the operational context. If generic advice would remove required functionality, do not blindly apply it. Instead, understand the requirement and look for a safer configuration that preserves the capability.
01
Identify the conflict
State exactly which generic recommendation appears to conflict with the scenario.
02
Find the explicit requirement
Re-read the relevant wording and determine what functionality or access must be preserved.
03
Secure instead of blindly removing
Look for a way to reduce risk while maintaining the required capability.
04
Verify the result
Confirm both the defensive improvement and the required functionality after the change.
Worked scenario
Extract the requirements before deciding what to fix
This fictional example demonstrates the reasoning process. The point is not to memorize the names or exact situation; it is to practice translating scenario statements into defensive constraints.
Scenario statement 1
Jordan and Priya are authorized users. Priya is the only authorized administrator.
Defensive extraction
Jordan should have a legitimate account but does not automatically need administrative privileges. Priya is the explicitly authorized administrator.
Scenario statement 2
The workstation must continue supporting a required remote-management function.
Defensive extraction
Do not disable related functionality merely because remote access can increase risk. Determine how it is configured and secure it while preserving the requirement.
Scenario statement 3
The organization recently reported suspicious file activity.
Defensive extraction
Inspect relevant evidence and forensic questions before deleting files or performing broad cleanup that could remove useful clues.
Scenario statement 4
An unfamiliar account named temp-support exists but is not mentioned in the authorized-user information.
Defensive extraction
The account deserves investigation. Compare it against scenario requirements and system evidence before deciding what action is appropriate.
Common mistakes
Reading errors that become technical errors
Skimming for usernames only
The scenario can contain equally important requirements about services, software, networking, roles, or restrictions.
Treating the ReadMe as background
Operational requirements are part of the technical problem. They determine whether a security change is appropriate.
Starting the checklist while reading
Changing settings before finishing the scenario can create avoidable mistakes because later instructions may change the meaning of an earlier observation.
Assuming silence means permission
If something is unclear, mark it as an unknown and investigate. Do not invent scenario requirements that are not actually stated.
Forgetting the forensic questions
Questions may reveal what evidence matters. Reading them late can mean useful evidence has already been changed.
Failing to share extracted constraints
A teammate can accidentally undo required functionality if the scenario notes stay only in one person's head.
Reflection
Test your scenario reasoning
Question 1
A user is authorized but is not listed as an administrator. What should you verify before changing the account?
Question 2
A generic checklist recommends disabling a service, but the scenario says the capability is required. How should the team reason about the conflict?
Question 3
Why should suspicious-file clues and forensic questions be reviewed before broad cleanup?
Question 4
What is the difference between an unauthorized item and an unknown item?
Question 5
Why is a short shared scenario summary useful even if every teammate has access to the original ReadMe?
Question 6
What should you do when the scenario wording is ambiguous and a proposed change could be disruptive?
Scenario checklist
Before the first major change
01
Read the entire scenario before broad hardening.
02
Write down the machine's purpose.
03
List authorized users.
04
List authorized administrators separately.
05
Record required services and applications.
06
Record restrictions, exceptions, and must-not-change items.
07
Read forensic questions early.
08
Mark suspicious clues that may require evidence preservation.
09
Separate confirmed facts from assumptions.
10
Create an unknowns list for anything that needs verification.
11
Share the extracted constraints with teammates.
12
Re-read the scenario during final review.
Next strategy lesson
First 15 Minutes
Next, turn the scenario map into an organized opening workflow: coordinate the team, establish a baseline, protect evidence, identify high-confidence work, and avoid rushed changes.