The Collegiate Cyber Defense Competition (CCDC) gives you a network you’ve never seen, a list of services that have to stay up, and a professional red team whose whole job is to break in and knock them over.
In 2026 I competed with CyberHawks, Illinois Tech’s cybersecurity community, as part of an eight-person team.
Season at a glance
Round Date Result Illinois State Qualifier Feb 14, 2026 3rd place Midwest Wildcard Feb 21, 2026 4th place Midwest Regional (Purdue University Northwest) Mar 20–21, 2026 Competed
What CCDC is
Every team plays the blue team. You inherit a small company’s network (Windows and Linux servers, network devices and business services), and none of it is secure by default. You’re scored on three things at once:
- Uptime. A scoring engine checks the services all day. If one goes down, you lose points, even if you broke it.
- Injects. Business tasks keep coming in, the way they would for a real IT or security team.
- The red team. Experienced attackers look for weak credentials, exposed services and anything you forgot to lock down.
The hard part is doing all three together. Every security change comes with the question “will this break something that’s being scored?”
My role: Palo Alto firewall and Incident Reports
I owned the Palo Alto next-generation firewall protecting the Linux side of the network. Behind it sat an e-commerce website, a webmail server and our Splunk SIEM, all of which had to stay reachable for scoring while being defended from the red team.
Throughout the competition, I also wrote incident response (IR) reports, documenting what we detected and how we responded.
My approach came down to four ideas:
Protect the firewall first. If the red team controls the firewall, they control everything behind it. So before touching any traffic rules, I took control of the admin accounts, turned off insecure management access, made sure only one trusted internal machine could reach the management interface, and saved a known-good configuration.
Allow only what’s needed. Explicit rules for the scored services, and deny-and-log for everything else. That included traffic between internal servers. A web server has no reason to open an SSH session to another server, and that kind of east-west traffic is exactly how an attacker moves laterally.
Inspect what you allow. Allowing web traffic doesn’t tell you whether it’s a customer or an exploit. I used zone protection against scans and floods, vulnerability and anti-spyware profiles on the allowed traffic, and log forwarding to our SIEM (Splunk). The tuning was the tricky part: profiles that are too aggressive also block the scoring engine, so the goal was to block critical and high-severity threats and alert on the rest.
Don’t panic-fix. When a scored service goes red, it’s tempting to throw in an “allow everything” rule just to get it back. That’s also the easiest gift you can give the red team. The better habit is to read the logs, figure out what’s actually being dropped, and allow exactly that.
What I watched for
Once the hardening was done, the job became monitoring. The red team doesn’t only attack servers. If they get in anywhere, they’ll try to quietly undo your defenses. So alongside the traffic and threat logs, I kept checking the firewall itself:
- New rules I didn’t create, especially broad “allow” rules near the top
- Admin accounts that shouldn’t exist
- Security profiles quietly removed from allow rules
- Internal servers talking out to places they had no reason to reach
Preparation
CCDC is not a competition you can wing. We spent a lot of time preparing together in a dedicated lab. On my side, I built a playbook for the firewall: what to do in the first minutes, how to approach the rules, what to watch during the day, and what to do when something goes wrong. The logic was simple. Under pressure, you don’t want to be thinking about the order of steps. You want to already know it.
Part of that preparation was making judgment calls in advance. A good example is the classic “should we patch this right now?” question. Updating a firewall’s software in the middle of a competition means downtime and the risk that it doesn’t come back cleanly, and while it’s down, every service behind it is exposed. Working through that ahead of time meant the plan was to reduce exposure and watch for exploitation attempts, rather than gamble on a mid-competition update.
What changed between rounds
A lot. In the qualifier, my focus was getting the configuration right. By the later rounds, I understood why it was set up that way, and I could actually read the firewall.
The biggest shift was understanding command-and-control (C2) traffic. A compromised machine usually “beacons” back to the attacker with small, regular check-ins asking for instructions, and outbound SSH from a server that should never initiate it is a classic sign. That changed how I saw the job. Keeping attackers out is half of it. Catching a compromised machine trying to phone home is the other half.
Results
CyberHawks at the 2026 Illinois State Qualifier, where we placed 3rd.
CyberHawks at the 2026 Midwest Wildcard, where we placed 4th.
CyberHawks at the 2026 Midwest Regional at Purdue University Northwest.
The Midwest Regional was two days long. It was quite a couple of days to remember: exciting, a little stressful, and full of learning curveballs.
What I learned
- Availability is part of security. A locked-down service that doesn’t work is still a failure.
- Protect the thing that protects everything else. The firewall’s own management access matters more than any single rule on it.
- Defaults are decisions. They’re usually chosen for convenience, not security.
- Watch outbound, not just inbound. A compromised machine often gives itself away on the way out.
- Write the playbook before the stress. The preparation you do when things are calm is what you rely on when they aren’t.
If you’re new to CCDC and want a deeper look at how the competition works, WinterKnight’s CCDC hub is one of the best guides out there.
Thank you
To my CyberHawks teammates: thank you for all the hard work we put into this season together, and for showing up every single time.
Thank you to Professor Jeremy Hajek for giving us access to the Smart Lab where we could sit down and actually prepare for the competition, and to Dr. David Durkee for organizing the Midwest Regional and giving us the chance to compete there.
*More about my background: About