Cyber Conquest
A king-of-the-hill competition where every team defends its own infrastructure while attacking everyone else's. I held the defensive side — firewalls, service hardening, traffic monitoring — and helped on offense between incidents.
Cybersecurity · Digital forensics
B.S. Cyber Operations, Dakota State University — graduated May 2026.
Cybersecurity and digital forensics are two ends of the same problem, and I work at both. Defense is what happens while a system is running — hardening services, watching traffic, responding when something breaks. Forensics is what happens after: reconstructing events from a disk image or a packet capture, and documenting them clearly enough for someone else to act on.
I've defended live infrastructure in attack/defense competitions, built web applications end to end, and spent a year teaching 4th–6th grade girls to code through NCWIT. I'm looking for roles in security operations, incident response, and digital forensics.
A king-of-the-hill competition where every team defends its own infrastructure while attacking everyone else's. I held the defensive side — firewalls, service hardening, traffic monitoring — and helped on offense between incidents.
A multi-page site with image galleries and forms, backed by a Node.js API with full CRUD for mailing-list subscribers.
Projects & competitions
Coursework, competition, and side projects — the ones where I learned something I still use.
Notes & write-ups
Case notes, competition write-ups, and things I figured out the hard way.
Most cybersecurity coursework hands you one job at a time. You harden a box, or you find a way into somebody else's. Cyber Conquest hands you both at once and starts the clock.
The format is king-of-the-hill: every team runs its own infrastructure, every team is trying to take everyone else's, and points accrue for as long as you hold ground. I played primary defender, which sounds like the calmer seat until you realize the person next to you needs your attention on offense and your firewall rules are already three revisions behind.
The thing a lab exercise can't teach you is what to ignore. In a lab, every alert matters, because the exercise put it there. In competition, most of what crosses your screen is noise or someone else's problem, and the cost of chasing it is that the real intrusion gets twenty uninterrupted minutes.
What worked for me was deciding in advance what "up" meant for each service, and only reacting to things that threatened it. Everything else went in a list to look at when the board was quiet.
The other lesson was documentation. When you're hardening under pressure it feels like a waste of thirty seconds to note what you changed — until you're rolling back at hour three and can't remember whether the config that broke was yours or theirs.
That habit is the part I carried into forensics work. The analysis isn't finished when you understand what happened; it's finished when someone else can read your notes and reach the same conclusion.
PlaceholderThis is a sample post so the blog has something in it. Replace it with your own writing whenever you're ready — the layout will handle any length.