Competition Strategy 01

Competition Strategy Overview

Learn the reasoning process that should guide every CyberPatriot task before you dive into individual operating systems, networking, or forensics.

A strong team does not simply apply as many security settings as possible. It understands the mission of the image, observes the current state, prioritizes evidence, makes controlled defensive changes, verifies the result, and keeps track of what still needs attention.

Lesson Snapshot

Core workflow6 phases

Main skillReasoning

Applies toEvery image

GoalControlled defense

Learning objectives

What you should understand before moving on

Explain why CyberPatriot work should begin with the scenario instead of a generic hardening checklist.

Describe the six-phase competition workflow: understand, baseline, prioritize, fix, verify, and review.

Separate high-confidence defensive changes from changes that need more evidence.

Explain why required users, services, software, and network functions must be protected.

Use a simple change log to improve team coordination and troubleshooting.

Recognize when to stop, investigate, ask for a second opinion, or return to a task later.

Core idea

CyberPatriot is a decision-making competition

Technical knowledge matters, but knowing a command or setting is only part of the job. You also need to decide whether the change is appropriate for this image, this scenario, and this moment.

The same setting can be safe in one situation and disruptive in another. That is why scenario awareness, evidence, verification, and communication are part of technical skill rather than separate from it.

Important warning

Hardening without context can reduce security

A change that breaks a required service, locks out a legitimate administrator, destroys forensic evidence, or interrupts networking can make the image less useful even if the setting sounds secure in isolation.

Never treat a generic checklist as permission to change every setting. Use the checklist to remember where to look, then use evidence to decide what to change.

Six-phase workflow

The cycle that guides the entire round

The phases are shown in order, but real competition work is iterative. You may return to baseline, investigation, verification, or review many times as new evidence appears.

Phase 01

Understand

What is this system supposed to do?

Before changing settings, understand the scenario, ReadMe, required users, required services, special restrictions, and forensic questions. A secure configuration is only useful if it still satisfies the mission of the image.

Read the entire scenario before making broad changes.

Highlight required accounts, administrators, applications, and services.

Identify instructions that change what would normally be considered a best practice.

Read forensic questions early so evidence is not accidentally changed first.

Phase 02

Baseline

What is true right now?

A baseline is the team's understanding of the system before major changes. It helps distinguish existing problems from side effects created by the team and gives everyone a shared picture of the machine.

Review users, groups, and administrative access.

Check major security tools and update status.

Identify important services, applications, and network functions.

Record obvious issues without immediately changing every one of them.

Phase 03

Prioritize

What should we work on first?

Not every issue deserves immediate attention. Strong prioritization balances confidence, impact, risk, time, and evidence. High-confidence problems can often be handled first, while uncertain or disruptive tasks should be investigated.

Handle clear, high-value issues before low-impact time traps.

Separate fixes from investigation tasks.

Flag risky changes that may affect required services or networking.

Keep an unresolved list instead of repeatedly getting stuck on one item.

Phase 04

Fix

What controlled change should we make?

A defensive change should have a reason. Teams should know what problem they are addressing, what setting or command changes it, and what could break if the assumption is wrong.

Make one logical change at a time when possible.

Use the least disruptive change that solves the identified problem.

Communicate major changes to teammates.

Record commands, settings, and important observations.

Phase 05

Verify

Did the change actually help?

Verification separates controlled defense from random configuration changes. After an important change, confirm the desired condition improved and that required functionality still works.

Re-check the setting, status, service, user, or policy that was changed.

Confirm required connectivity or application functionality still works.

Look for errors or new symptoms after high-impact changes.

Record whether the result was successful, uncertain, or needs follow-up.

Phase 06

Review

What are we still missing?

The final phase is not simply the last few minutes. Teams should review throughout the round. Re-read requirements, revisit unresolved items, verify forensic answers, and check risky changes before time runs out.

Return to the scenario and confirm explicit requirements.

Review the unresolved-task list.

Revisit forensic questions and supporting evidence.

Stop making unnecessary last-minute changes that cannot be verified.

Evidence first

What counts as a reason to make a change?

A defensive decision becomes stronger when you can connect it to one or more forms of evidence. Evidence does not mean you must wait forever. It means you can explain why the change makes sense.

Scenario evidence

The instructions state that a user, service, application, role, or capability is required or prohibited.

System evidence

The machine itself shows an unsafe state, suspicious configuration, unauthorized account, disabled protection, outdated software, or another concrete issue.

Policy evidence

A security requirement or organizational rule explains how a setting should be configured.

Log or forensic evidence

Logs, files, processes, metadata, or other evidence support a conclusion that should affect the team's decision.

Ask before changing

What specific problem am I trying to solve?

What evidence tells me this is actually a problem?

Does the scenario require this user, service, application, or capability?

Could this change affect networking, authentication, permissions, or a required service?

How will I verify that the change worked?

What will I do if the change causes a problem?

Change tracking

A simple log improves technical reasoning

Documentation does not need to be complicated. The goal is to preserve enough context that the team understands what happened and can troubleshoot or reverse a risky decision later.

Observation

An account has administrator rights but is not listed as an authorized administrator in the scenario.

Reasoning

The scenario defines which administrators are authorized, so this privilege assignment requires review.

Action

Remove only the unauthorized administrative privilege after confirming the account itself is still required.

Verification

Confirm the account remains usable if required and is no longer a member of the administrative group.

Team communication

Major changes should never surprise your teammates

Teams can divide responsibilities, but they should not become isolated. Important changes to users, services, networking, authentication, permissions, firewalls, or server roles can affect other work.

Say what you are about to change when the change could affect another teammate's work.

Report unexpected errors, lost connectivity, failed services, or authentication problems immediately.

Keep a shared unresolved list so difficult tasks do not vanish when someone moves to another part of the image.

Ask for a second opinion before a disruptive change when the evidence is incomplete.

Common strategy mistakes

Habits that create avoidable problems

Changing everything immediately

A long checklist can make students feel productive, but it can also break required functionality and hide which change caused a problem.

Assuming every unusual account is malicious

Some accounts may be required by the scenario. Verify before removing or disabling them.

Disabling services without understanding them

A service may support a required role, application, remote-access method, or dependency. Investigate before disabling it.

Ignoring forensic questions until the end

Changes made earlier in the round may alter useful evidence. Read the questions early and protect what matters.

Working silently

If teammates do not know about major changes, they can duplicate work, undo each other, or misdiagnose a later problem.

Spending too long on one mystery

A difficult problem can consume the time needed for many clearer tasks. Record it, move on, and return with fresh evidence later.

Practice scenario

Apply the workflow before touching the setting

Scenario fact

A machine is required to provide a legitimate service during the round.

Observation

The service appears in a generic hardening checklist as something that is often disabled.

Weak approach

Disable it immediately because the checklist says it can reduce attack surface.

Better approach

Recognize that the scenario requirement overrides the generic checklist. Keep the required service available, then secure its configuration instead of removing the capability.

The lesson is not “never disable services.” The lesson is that a security action must fit the scenario. Required functionality must be protected while the underlying configuration is reviewed and secured.

Reflection

Check your reasoning

Question 1

Why can a generic security checklist be dangerous if it is used without reading the scenario?

Question 2

What is the difference between finding an unusual setting and having enough evidence to change it?

Question 3

Why should forensic questions be read near the beginning of a round?

Question 4

What makes a change high risk even when it improves security in general?

Question 5

How does a change log help when a teammate reports that something stopped working?

Question 6

When should a team temporarily move on from a difficult problem?

Strategy checklist

Keep these habits visible during practice

Read the scenario and ReadMe completely.

Identify required users, administrators, services, applications, and restrictions.

Read forensic questions before changing evidence-rich areas.

Assign responsibilities and establish communication expectations.

Baseline the system before broad hardening.

Create a high-confidence task list and a separate investigation list.

Make controlled changes with a clear reason.

Record important changes and commands.

Verify both security improvement and required functionality.

Revisit unresolved items instead of repeating failed approaches.

Re-read the scenario before the final review.

Avoid unverified last-minute changes.

Next strategy lesson

Read the Scenario First

The next lesson will show how to extract required users, services, software, restrictions, and investigation tasks from the scenario before the team begins hardening.

Open Lesson 02 →

Back to Competition Strategy

Next Lesson →