Competition Checklist · 01 · Strategy
Competition Start Checklist
Use the opening minutes to understand the mission, protect required functionality, assign ownership, capture a baseline, and identify the highest-value work before the team starts changing configuration.
A disciplined start saves time later because the team knows what must remain working, who is authorized, what evidence matters, and who owns each system.
Quick Use
Opening rule
Read first. Change second.
A familiar hardening step can still be wrong if the scenario requires the account, service, share, protocol, role, or network path. The competition brief is the source of truth for what must remain.
First 10 minutes
Do these before deep remediation
Read the entire scenario before changing anything.
Required users, services, shares, roles, remote access, and network behavior may be different from your usual hardening assumptions.
Highlight every requirement that must remain functional.
Competition mistakes often happen when a team secures one setting but accidentally breaks something the scenario explicitly requires.
Record approved users and approved administrators.
This gives the team a trusted reference before anyone removes accounts or changes group membership.
Identify required services and remote-access methods.
Do not disable SSH, RDP, SMB, web services, or other listeners until you know whether the mission depends on them.
Assign a primary owner for each platform.
One person should be accountable for Windows, Server, Linux, Cisco, or forensics work instead of several teammates changing the same system at once.
Start one shared change log.
Every meaningful change should have a time, owner, reason, command or setting, and verification result.
Capture the initial state before remediation.
A baseline helps you prove what existed before your team made changes and gives you something to compare against later.
Identify obvious high-risk findings, but do not deep-dive yet.
The opening phase is for orientation and prioritization, not spending twenty minutes on the first unusual setting you notice.
Mission extraction
Turn the scenario into a working reference
Write these down before anyone starts account cleanup, service hardening, or network changes.
Approved users
Write down every user who is explicitly authorized to remain on each system.
Approved administrators
Record which users may hold local admin, Domain Admin, sudo, enable, or other privileged access.
Required services
List services, roles, shares, websites, applications, and network paths that must stay functional.
Remote access
Record whether RDP, SSH, Telnet, VNC, WinRM, or other remote access is required or unnecessary.
Network requirements
Record VLANs, subnets, routes, management paths, allowed services, and any required reachability.
Security requirements
Record explicit requirements for antivirus, firewall, updates, password policy, logging, auditing, and account controls.
Forbidden changes
Note anything the scenario says not to remove, stop, uninstall, disable, reset, or reconfigure.
Evidence questions
Record any forensic, incident, or explanation questions that require preserving evidence before remediation.
Team ownership
Give each platform a clear primary owner
Windows 11 lead
Local users, Administrators, Defender, Firewall, updates, services, startup, scheduled tasks, processes, listeners, shares, and Windows event evidence.
Windows Server lead
Privileged identities, server roles, SMB shares, sessions, services, RDP, firewall state, authentication evidence, and required server dependencies.
Linux lead
Users, groups, sudo, permissions, packages, services, SSH, firewall state, cron, systemd timers, processes, sockets, and authentication logs.
Cisco / networking lead
Interfaces, VLANs, trunks, access ports, routing, ARP, ACLs, VTY access, SSH, port security, logging, and required reachability.
Forensics / coordinator
Evidence preservation, hashes, timeline notes, cross-system correlation, team status, and the shared change log.
Baseline
Capture enough state to know what changed
Identity
Know who exists and who is privileged before account cleanup begins.
Security controls
Confirm foundational protections before lower-priority tuning.
Services
Separate mission-required functionality from unnecessary exposure.
Processes and persistence
Identify recurring or active behavior that may deserve higher priority.
Network state
Understand current connectivity before changing network policy.
Evidence
Preserve useful context before changes alter system state.
Priority model
Decide what deserves attention first
Active high-impact risk
Preserve evidence, confirm scope, and address immediately with the smallest justified change.
Privilege or remote-access exposure
Investigate quickly and remediate after confirming the mission does not require the access.
Important hardening issue
Record and fix after active risk and mission-critical issues are stable.
Benign or mission-required
Document why it is expected so the team does not repeatedly investigate it.
Shared change log
Record every meaningful change
The change log should be simple enough that the team actually uses it. One row per meaningful finding or remediation is usually enough.
Avoid these opening mistakes
The fastest start is not the most aggressive start
Changing settings before reading the scenario
The team may remove required users or break services that were explicitly supposed to remain enabled.
Everyone working on the same image
Changes collide, evidence is lost, and nobody knows who changed what.
Disabling every unfamiliar service
Required functionality can fail and the team may lose time rebuilding what it broke.
Treating every unusual setting as equally urgent
Low-value hardening can consume time while active privilege or persistence remains unresolved.
No change log
Verification becomes difficult and teammates may repeat or reverse each other's work.
Skipping the baseline
Later, the team cannot tell whether a problem existed before remediation or was introduced by a teammate.
Opening decision questions
Ask these before the first high-impact change
What absolutely must remain working?
Which users are explicitly approved?
Who is allowed to be privileged?
Which remote-access methods are required?
Which systems or services appear most exposed right now?
What evidence could be destroyed by an early change?
Which teammate owns each platform?
Where will all changes and verification results be recorded?
Ready to move on
Start remediation only when the team can answer these basics
The full scenario has been read by at least the platform owners.
Required users and administrators are recorded.
Required services, shares, roles, applications, and network paths are recorded.
Remote-access requirements are recorded.
A platform owner is assigned to each system area.
A shared change log is open and ready.
The baseline state has been captured before major remediation.
High-risk findings have been separated from lower-priority hardening.
No required service has been disabled during the opening review.
The team knows what to investigate first and what can safely wait.