Competition Day Guide · Guide 07 · Work Cycles
Platform Work Cycles
The main round should feel controlled even when the technical work is different on every platform. Inspect, decide, change narrowly, verify, and document without forcing Windows, Linux, Cisco, and forensics into identical technical steps.
The repeated discipline is the decision process, not a rigid checklist. Each platform still needs the tools and reasoning that fit its own architecture.
Work-Cycle Goal
Work-cycle rule
One justified change is easier to verify than five simultaneous changes
Controlled work preserves cause and effect. When several variables change at once, the team may not know which action improved the system or which action broke required functionality.
Core cycle
Use a repeatable decision discipline
The cycle stays consistent even when the technical checks differ by platform.
01
Inspect
Collect enough current-state evidence to understand the account, service, process, task, rule, interface, or file before changing it.
02
Decide
Compare the evidence with the mission, required functionality, team priorities, and likely risk of the proposed action.
03
Change Narrowly
Apply the smallest justified remediation instead of bundling several unrelated changes together.
04
Verify
Confirm both the intended security result and the required mission function that could have been affected.
05
Document
Record the original state, evidence, change, verification, unresolved questions, and any dependency the team should know.
Platform patterns
Keep the discipline consistent while letting the technical work stay natural
Windows 11
Focus
Accounts, local Administrators, Defender, Firewall, RDP, services, scheduled tasks, startup items, event evidence, and mission applications.
Caution
Avoid broad service disabling, mass account cleanup, or firewall rewrites without dependency evidence.
Windows Server
Focus
Roles, domain or local identity, service accounts, shares, NTFS permissions, remote management, event evidence, and role dependencies.
Caution
A server change can affect many users at once, so verification must include the role it is supposed to provide.
Linux
Focus
Users, sudo, permissions, SSH, services, systemd, cron or timers, listeners, logs, packages, and required applications.
Caution
Avoid recursive permission changes, unvalidated sudoers edits, and service removals based only on unfamiliar names.
Cisco & Networking
Focus
Interfaces, VLANs, trunks, routes, ACLs, management access, port security, counters, and end-to-end reachability.
Caution
Change one layer at a time so the team can tell whether a failure comes from switching, routing, policy, or management access.
Forensics
Focus
Preservation, hashes, timestamps, processes, logs, account evidence, persistence clues, network artifacts, and timeline correlation.
Caution
Preserve evidence before remediation and avoid turning a suspicious clue into a conclusion without correlation.
Shared Operations
Focus
Priority board, evidence log, handoffs, dependencies, verification ownership, and team-wide risk decisions.
Caution
Platform work is not complete until the team can understand what changed and whether it was verified.
Stop points
Pause when the evidence, dependency, or recovery path is unclear
The proposed change affects a required service or role.
The team cannot explain why the current state is unsafe.
The evidence is based only on an unfamiliar name or setting.
The rollback path is unclear.
Another teammate is already changing the same system.
The change crosses platforms or dependencies.
Verification would require a reboot or other high-impact action.
The round is late enough that recovery time is shrinking.
Verification layers
Prove security improvement without losing the mission
Security Result
Did the risky condition actually improve?
Identity
Can approved users and administrators still authenticate as expected?
Service
Does the required service still start and perform its intended role?
Network
Can required traffic still reach the intended destination?
Application
Does the mission application or workflow still function?
Persistence
Will the secure state survive restart, reload, or service recovery when appropriate?
Work-cycle record
Capture enough context for verification, rollback, and handoff
System / platform
Owner
Finding
Evidence
Mission dependency
Planned change
Rollback path
Security verification
Mission verification
Final status
Unresolved question
Next action
Weak habit vs better habit
Replace fast-looking work with controlled progress
Weak habit
Make every obvious fix on the page before testing anything.
Better habit
Make one justified change, verify it, document it, then continue with the next issue.
Weak habit
Use the exact same checklist order on every platform.
Better habit
Use the same decision discipline while allowing each platform to follow its natural technical structure.
Weak habit
If a setting looks insecure, change it immediately.
Better habit
Inspect mission context, dependencies, and evidence before changing high-impact settings.
Weak habit
Verification means the command completed without an error.
Better habit
Verification means the security objective was achieved and required functionality still works.
Weak habit
Document only major findings.
Better habit
Document enough original state, change, verification, and unresolved context to support handoffs and rollback.
Weak habit
Keep working until the platform looks perfectly hardened.
Better habit
Stop when higher-value work exists elsewhere or when further changes carry more risk than likely benefit.
Escalation signals
Some work should become a team decision
Required functionality breaks after a change.
Evidence conflicts with the mission instructions.
Two systems appear to depend on the same account, service, or network path.
A platform owner cannot safely verify the result alone.
Rollback fails or the original state cannot be restored.
A high-impact change is proposed late in the round.
The same issue keeps reappearing after remediation.
The team cannot agree whether the finding is actually malicious or unauthorized.
Cycle questions
Ask these before moving to the next change
Are we inspecting before changing?
Is the change tied to mission context and evidence?
Is this the smallest effective remediation?
Do we know how to undo it if verification fails?
Are we checking both security and mission functionality?
Is the result recorded in the shared team log?
Does another teammate need to know about a dependency?
Is this still the highest-value use of time?
Platform Work Cycles final checklist
Keep progress explainable, verifiable, and safe to hand off
Each active platform has one clear owner.
Inspection happens before high-impact remediation.
Mission dependencies are considered before changes.
Broad changes are broken into smaller verifiable actions.
Rollback is understood for risky work.
Security results are verified after changes.
Required services and workflows are also verified.
Important evidence is preserved before remediation.
The shared log reflects current platform status.
Cross-platform dependencies are escalated early.
Low-value perfection does not block higher-priority work.
Risk tolerance decreases as the round gets later.