Common Mistakes · Guide 01 · Strategy
Competition Strategy Mistakes
The biggest competition mistakes often happen before a command is ever typed: skipping the mission, prioritizing poorly, changing too much at once, working without ownership, and failing to verify.
Strong strategy does not mean moving slowly. It means spending a few deliberate moments to prevent hours of recovery later.
Quick Use
Strategy rule
Fast work is only useful when the team knows what must not break
Competition strategy should reduce uncertainty. Read the mission, establish ownership, preserve the original state, and decide which findings deserve action before the team starts making large changes.
Opening questions
Answer these before the main hardening pass
Which users and administrators are approved?
Which services and applications must remain available?
Which remote-access methods are required or forbidden?
Which network paths, VLANs, shares, or roles are mission-critical?
Are there explicit restrictions on what the team may change?
Which systems are likely to contain forensic questions or evidence?
Which teammate owns each platform or major task?
What is the first high-risk item that deserves investigation?
10 common mistakes
What goes wrong and what to do instead
Skipping the mission
What goes wrong
Teams sometimes begin hardening immediately without first extracting required users, services, remote-access needs, prohibited changes, and scoring constraints.
Why it hurts
A technically secure change can still be wrong if it breaks something the scenario explicitly requires.
Stronger replacement
Read the mission first, write down required functionality, and keep those requirements visible throughout the round.
Hardening before baselining
What goes wrong
Changing settings before recording the original state makes it difficult to explain what was already present and what the team changed.
Why it hurts
Evidence disappears, troubleshooting becomes harder, and the team may not know which change caused a regression.
Stronger replacement
Capture users, services, listeners, privileged groups, network state, and other high-value baseline information before major remediation.
Treating every unfamiliar item as malicious
What goes wrong
An unknown account, service, process, share, task, or listening port is sometimes removed simply because it is unfamiliar.
Why it hurts
Legitimate mission functionality, service dependencies, or useful forensic evidence can be destroyed.
Stronger replacement
Classify first: required, expected, suspicious, unnecessary, or unresolved.
Making broad changes
What goes wrong
Teams may disable many services, rewrite multiple firewall rules, change several ACL entries, or remove many privileges at once.
Why it hurts
If something breaks, the cause is unclear and recovery becomes slower.
Stronger replacement
Make one justified change at a time whenever practical and verify the result before continuing.
Chasing low-value hardening first
What goes wrong
Teams sometimes spend early time on cosmetic or low-impact settings while unauthorized privilege, suspicious persistence, or broken required services remain unresolved.
Why it hurts
High-risk issues survive while valuable competition time is lost.
Stronger replacement
Prioritize findings by mission impact, security impact, evidence confidence, and reversibility.
No clear ownership
What goes wrong
Multiple teammates may investigate or modify the same platform without knowing what others are doing.
Why it hurts
Work is duplicated, changes conflict, and evidence or required functionality may be lost.
Stronger replacement
Assign clear platform or task ownership and use short status handoffs.
Changing without evidence
What goes wrong
A setting may be changed because it feels insecure rather than because the mission, configuration, logs, or observed behavior support the decision.
Why it hurts
The team cannot explain why the change was justified and may create a new problem.
Stronger replacement
Tie meaningful changes to mission requirements, observed evidence, or a clearly tested security need.
Skipping verification
What goes wrong
Teams may assume a change worked because the command completed or the setting saved.
Why it hurts
Required functionality may be broken while the team continues working unaware.
Stronger replacement
After each high-impact change, verify both the security result and the mission function it could affect.
Waiting too long to document
What goes wrong
Important changes and findings are sometimes written down only near the end of the round.
Why it hurts
Commands, evidence, reasons, and unresolved questions are forgotten.
Stronger replacement
Use a shared change log continuously and record important work while the context is fresh.
Overreacting to time pressure
What goes wrong
As the clock drops, teams may become more aggressive and start risky changes because they feel they must keep doing something.
Why it hurts
Late regressions are harder to diagnose and may be impossible to recover before the round ends.
Stronger replacement
Reduce risk as time decreases. Shift toward verification, documentation, and stability.
Priority model
Do the highest-value work first
P1
Mission-breaking or critical security issue
Examples include required service failure, unauthorized administrative access, dangerous persistence, or a broken network path.
P2
High-confidence security weakness
The evidence is strong, the remediation is understood, and the chance of breaking required functionality is manageable.
P3
Useful hardening
The change improves security but is less urgent than confirmed privilege, persistence, service, or network issues.
P4
Low-confidence or cosmetic item
The finding is weakly supported, low impact, or not worth the risk under current time pressure.
Bad habit vs better habit
Replace vague competition instincts with explicit decisions
Weak habit
Disable anything that looks unnecessary.
Better habit
Identify the service owner, dependency, mission requirement, and listener before deciding whether it is unnecessary.
Weak habit
Delete suspicious users.
Better habit
Compare the account with the approved roster, preserve evidence, and remove only the unauthorized access that is justified.
Weak habit
Lock everything down first.
Better habit
Baseline first, then harden only what is supported by the mission and evidence.
Weak habit
Fix as much as possible before time runs out.
Better habit
Fix the highest-value issues first and lower risk as the clock gets shorter.
Weak habit
Everyone should help everywhere.
Better habit
Use clear ownership with concise cross-team handoffs when dependencies overlap.
Weak habit
If the command worked, the issue is fixed.
Better habit
Retest the security control and required functionality after the change.
Mid-round warning signs
These signals mean the team should stop and verify
Required service unexpectedly stopped
Approved user lost access
Suspicious listener returned
A teammate cannot explain a recent change
Network reachability changed after a policy edit
Evidence needed for a forensic question was altered
Two teammates are working the same issue independently
The change log is missing important work
Strategy final checklist
Strong competition habits before moving on
The mission was read before major hardening began.
Required users, services, remote access, and network needs were recorded.
The team established a baseline before broad remediation.
High-impact work was prioritized ahead of cosmetic hardening.
Unknown items were investigated before removal.
Meaningful changes were supported by evidence or mission requirements.
Large changes were broken into smaller verifiable steps when practical.
Platform ownership was clear.
Important findings and changes were documented as they happened.
Required functionality was rechecked after high-impact changes.
Mid-round regressions were investigated before more hardening continued.
Risk tolerance decreased as the competition clock ran down.