Competition Day Guide · Guide 05 · Mission Extraction
Mission & README Extraction
The scenario is a technical constraint document. Extract the users, services, access paths, network relationships, special restrictions, and mission-critical functions before broad hardening begins.
The goal is to turn prose into a shared operating record that guides decisions and gives the team clear verification targets.
Extraction Goal
Mission rule
Do not harden away the function you are supposed to defend
Security decisions should preserve the required mission. A setting can be more restrictive and still be wrong if it disables an approved user, required service, remote-access method, application, share, or network path.
What to extract
Turn the scenario into six categories of constraints
Approved users
Write down which users are expected to exist, which accounts are administrators, and whether any special-purpose identities are explicitly required.
Required services
Record the services, roles, applications, shares, websites, or network functions that must remain available during the round.
Remote access
Identify whether RDP, SSH, WinRM, VPN, console access, or another management path is required, optional, restricted, or prohibited.
Network requirements
Capture required IP relationships, VLANs, routing behavior, DNS, gateway, or reachability expectations described in the scenario.
Special constraints
Record explicit do-not-change instructions, required software, protected files, evidence requirements, or platform-specific limitations.
Scoring-sensitive functions
Mark anything whose failure would affect mission availability so the team verifies it after related changes.
Extraction process
Move from reading to an operational mission record
01
Read once without editing
Read the scenario from beginning to end before changing settings. The first pass builds context and prevents isolated details from being misunderstood.
02
Highlight mission requirements
Mark users, services, access paths, network functions, applications, files, and restrictions that the team must preserve.
03
Separate facts from assumptions
Only place explicit scenario statements into the mission record. Keep uncertain interpretations in a separate notes area.
04
Assign platform owners
Route each requirement to the teammate responsible for that platform so nobody misses a critical dependency.
05
Create verification targets
Turn mission requirements into checks the team can repeat after changes and again late in the round.
06
Keep the mission visible
The extracted mission should stay open or easy to reach so it remains part of technical decision-making throughout the round.
Shared extraction board
Give each mission requirement an owner
Common extraction mistakes
Do not replace the scenario with assumptions
Reading only the first paragraph and beginning changes immediately.
Treating every unfamiliar user as unauthorized.
Disabling a service because it is not personally familiar.
Assuming RDP or SSH should always be disabled.
Ignoring application or share requirements while hardening the host.
Forgetting that a network rule can break a required service even when the host itself is healthy.
Mixing explicit scenario requirements with guesses or habits from previous rounds.
Keeping mission details in one teammate's private notes instead of the shared team view.
Failing to turn requirements into verification checks.
Not revisiting the mission before late-round high-impact changes.
Weak extraction vs better extraction
Convert vague scenario memory into usable technical constraints
Weak approach
The README says web server, so just leave port 80 open.
Better approach
Record the required web function, identify the actual service and path that support it, then verify that function after any firewall or service change.
Weak approach
This account looks suspicious, so remove it.
Better approach
Check whether the account is listed as approved, privileged, service-related, or otherwise required before changing it.
Weak approach
Remote access is insecure, so disable it.
Better approach
First determine whether the scenario requires RDP, SSH, WinRM, VPN, or another management path, then secure only what is actually required.
Weak approach
We already read the mission at the start.
Better approach
Keep the extracted mission visible and re-check it before high-impact or late-round changes.
Weak approach
Everyone can remember the important requirements.
Better approach
Turn explicit requirements into a shared record with owners and verification targets.
Weak approach
If the system still boots, the mission is fine.
Better approach
Verify the actual required application, share, remote-access path, route, or service after related changes.
Verification targets
Turn mission requirements into checks the team can repeat
Required user can still authenticate when appropriate.
Required administrator or privileged path still exists.
Required service is running.
Required application or role responds correctly.
Required share or file path is reachable.
Required remote-access method still works when permitted.
Required network path still passes expected traffic.
Required DNS / gateway behavior remains correct.
Protected evidence remains intact.
Scenario-specific restrictions are still being respected.
Mission questions
The team should be able to answer these before broad hardening
Which users are explicitly approved?
Which users are allowed to be administrators or privileged?
Which services or applications must remain operational?
Which remote-access methods are required or prohibited?
Which hosts or networks must communicate?
Which files, shares, roles, or applications are mission-critical?
What actions does the scenario explicitly prohibit?
Which findings need evidence preserved before remediation?
What should be verified after every related change?
What remains uncertain and should not be guessed?
Mission & README final checklist
Finish extraction with a shared mission record the team can use
Scenario / README was read completely before major changes.
Approved users were extracted.
Approved privileged users were extracted.
Required services and applications were recorded.
Required remote-access paths were recorded.
Required network relationships were recorded.
Special restrictions were recorded.
Protected files or evidence requirements were recorded.
Each mission requirement has a platform owner.
Verification targets were created for critical functions.
Assumptions are separated from explicit scenario facts.
The extracted mission remains visible to the team.