My Starting Point

I came to Old Dominion University with an A.S. in Cyber Security from Tidewater Community College and a CompTIA Security+ certification I earned in 2023, before I finished high school. On paper I was ready. I knew the vocabulary, I could name the tools, and I had passed the exam that a lot of entry-level job ads ask for. What I didn’t have yet was a sense of what any of it was for.

At that point, cybersecurity meant the technical side to me: scanning, exploiting, defending. I expected the offensive work to be what I loved most. I also came in with the uncertainty that comes with transferring. Moving from a community college to a four-year university meant a heavier workload and a faster pace, and I wasn’t sure how I would keep up with that on top of everything else I was doing. I knew I wanted a career in security, but I couldn’t have told you what kind, or why it mattered beyond being a good job.

The Journey

The courses that shaped me most were the ones that made me do the work myself. Linux Systems for Cybersecurity (CYSE 270) gave me the foundation: users and groups, file permissions, shell scripting, networking. Vim was the hardest part, and learning it taught me to keep pushing on a tool until it made sense. Cybersecurity Techniques and Operations (CYSE 301) moved me from theory into practice. In the Sword vs. Shield lab I scanned a subnet as the attacker, hardened the firewall, then scanned again to prove the fix worked. Cryptography for Cybersecurity (CS 463) took me underneath the tools. After working through ECC and ECDH by hand, I understood why systems pair symmetric and asymmetric encryption instead of choosing one.

Cybersecurity and the Social Sciences (CYSE 201S) changed how I thought about all of it. Both of my article reviews reached the same conclusion from different directions: technical controls fail when they ignore people. One was about how overconfident people are at spotting deepfakes, and the other was about workplace cultures that don’t trust their own security rules. That idea followed me into my internship.

At RFK Solutionz (CYSE 368) I did IT deployment, built CMMC Level 1 and Level 2 compliance documentation, co-developed an offensive security presentation and CTF, and helped run Cyber Academy for about 50 K–12 students. Watching kids who weren’t used to being believed in light up when I told them they could do this changed my direction. I stopped wanting only to secure systems. I wanted to help the people who use them.

The challenges weren’t always technical. This fall I’ve been balancing my classes, my internship work, and a twice-weekly youth cyber program I help teach, which leaves very little slack in a week. In late September I was sick for more than a week, missed an assignment and a tutoring appointment, and had to reach out to Professor Mize to get back on track. The compliance work was hard in a different way. CMMC scoping has no single right answer, so I had to defend my judgment calls instead of looking them up. That taught me to question my own assumptions before calling something finished.

The skills I’ve grown most are systems administration, security assessment, and the one I didn’t expect: writing for someone outside the field. In CYSE 301, getting a shell was half the job. The other half was explaining the risk and the fix so a non-technical reader could act on it.

Meaning-Making

When I look across my portfolio, one pattern keeps showing up. The work only becomes real when a system meets the people who use it. The clearest proof of that isn’t one assignment. It’s something that happened at home this October.

On October 4, my mouse cursor kept flipping to the loading spinner. I went looking for a misbehaving program and found a live SSH brute-force attack on my own desktop. Port 22 was forwarded on my router, and automated bots had been guessing passwords about every five seconds for more than eleven hours. I worked through the whole incident response loop on my own hardware. I contained it by stopping the service and removing the port forward. Then I checked for compromise in the OpenSSH and Windows Security logs. There were zero successful logins, but the attack had rolled both logs over, so I also changed my password to cover the gap I couldn’t see. Last, I fixed the root cause.

That was the turning point of my time at ODU, and it was humbling. I’m a cybersecurity major. I knew every layer that would have stopped this, and I had none of them in place. Knowing something and practicing it are different skills. That is exactly the gap between policy and practice I wrote about in CYSE 425W, and the gap my article reviews described in organizations.

So I rebuilt how I run my own technology, in the same order a real organization should: incident, then policy, then design. My rule now is that nothing at home is open to the internet. I turned an old laptop into an always-on Linux server, and everything on it is reachable only through a private WireGuard network (Tailscale), with firewall rules per service. In the two weeks since, I’ve built my own projects on top of it. The main one is Regimen, a system that runs my daily schedule (gym, meals, school, practice), sends reminders to my phone, and tracks whether I actually followed through. It also pulls my ranked League of Legends games from Riot’s API, records every game for review, and tells me to stop for the day after two losses in a row. A friend who coaches me can log in to a separate review site, watch my games with me in a synced room, and set my weekly goals. That site is the one public exception to my rule, and I treat it like one. It sits behind Cloudflare Access, its own login, a token check on every request, and a kill switch I can flip from my phone. Only two named accounts can change anything.

This is where my courses stopped being separate classes. Linux is the whole server, down to secrets stored in owner-only files. CYSE 301 is how I designed it, by asking what’s exposed and who can reach it before I asked what it should do. Cryptography is load-bearing now: WireGuard tunnels, TLS on every site, hashed passwords, and signed login tokens. CYSE 201S is the reason Regimen exists at all. Willpower doesn’t scale, but systems and accountability do. The two-loss rule is a behavior intervention, not a feature. My internship is in it too. I applied least privilege and documented every control so an outsider could verify it, the same mindset as a CMMC assessment.

All of that connects back to my values. I care about building systems that are safe and understandable for other people, not just for me. That’s the same instinct that made teaching Cyber Academy matter so much to me.

Looking Forward

I graduate in December 2026. My first goal is a role in security operations, systems administration, or governance and compliance. Those are the jobs my internship and coursework point toward, and they ask for the same things this program gave me: Linux, assessment tools, incident response, and the ability to document and explain controls. The titles I’m targeting first are SOC Analyst, Junior Systems Administrator, and Cybersecurity Compliance Analyst, especially CMMC work with the defense contractors here in Hampton Roads, where my internship research applies directly. Longer term, I want to go to law school and work where technology and policy meet. I’m already working toward that by advocating for the Virginia Cyber Safe Communities Act, a proposed state grant program for community cybersecurity education, and I’m preparing to meet with Delegate Cliff Hayes about it ahead of the 2027 General Assembly session.

I still have gaps. Visual design is my weakest area, on this portfolio and in my own projects. I want deeper experience with enterprise tools and cloud environments than a home lab can give. My server is now my running lab, so I’ll keep learning by building, breaking, and securing things there.

I plan to keep this portfolio as a living document. When I finish a significant project or a new role teaches me something, I’ll add it with the same structure I used here: context, the work, the evidence, and what I learned.

The ePortfolio Experience

IDS 493 asked me to do something I’d never done deliberately: curate a public identity for a reader who doesn’t know me. Before this course my work was a folder of files. Building the portfolio meant choosing what to include, explaining why each piece was there, and cutting what didn’t fit.

Professor Mize’s feedback pushed me in two directions. The first was structure. Her line that “an outside reader should not have to open a series of documents” to understand why something is there changed how I built every course page. Each one now explains what the course was, what I did, why I chose each artifact, and what I learned. The second was bringing more of myself into the site. My first version was artifacts and course numbers. She kept pointing me back to why I’m in this field, which is how the site ended up with the tagline “Technical skill, applied to real change.”

I also strengthened skills I didn’t expect this course to touch. I did an accessibility pass and wrote alt text for every artifact preview. I worked on visual design: I replaced the default ODU banner with my own design, used warm neutrals with one accent color, and tested every change on desktop and phone. And I learned organization. After Peer Review 2, I grouped the course pages under one Coursework menu and cut the top menu from 11 items on two rows to 7 on one. Those are small changes, but each one came from watching how someone else actually used the site.

The biggest thing the portfolio did was validate an approach I was already using. In my own projects, my rule is that a change isn’t done until it’s documented clearly enough for someone else to follow. The portfolio is the same discipline aimed at a different reader. Writing it made me better at saying what I can do and why it matters, not just listing tools.

My advice to someone starting a portfolio is to start with why you’re in your field, not with your files. Pick fewer artifacts and explain each one. Ask someone outside your major to click through it, and watch where they get lost. Most importantly, include the things that went wrong and what you did about them. My best evidence turned out to be a mistake I made at home and how I fixed it.

Conclusion

The cybersecurity program at ODU is interdisciplinary on purpose, and I understand why now. The field ended up needing that mix because so many breaches aren’t technical failures. They’re human and organizational failures. My SSH incident wasn’t a knowledge gap. It was a habit and process gap, and no single discipline would have explained it. Linux and networking explain how the attack worked. Social science explains why I hadn’t acted on what I knew. Policy explains how to make sure it doesn’t happen again.

IDS 300W gave me the method for this. My research paper there looked at the growing wealth gap between the top 1% and average workers through economics, political science, and sociology. The concept that stuck with me was integration: each discipline explained one piece of why inequality grows and persists, but only by finding common ground between their insights could I see it as one self-reinforcing system. I didn’t realize until this semester that I had been using that same process on my own projects: drawing on systems, security, behavioral science, communication, and ethics, then integrating them into something that works for real people.

That is what I want to carry forward after ODU. I want to build systems that are secure, explain them so others can trust and verify them, and use that work to help people, the same way Cyber Academy showed me I could.