Starting Graduate School With a Problem Already in Hand

Classes start this week. I've been through orientation, sat in on a few talks from DePaul's College of Computing and Digital Media, and I'm about to begin a Master's in Cybersecurity with a concentration in Networking and Infrastructure. This post isn't about results yet, there aren't any from the program itself so far, it's about why I'm walking into this specific program with a specific problem already in hand, rather than showing up and figuring out what to work on once I get here.

Coming in with the problem already defined

Most people start a graduate program looking for direction. I'm starting mine already pointed somewhere, toward making threat intelligence accessible to organizations that can't afford the enterprise version of it. That's not because I had it all figured out in advance, it's because the problem showed up first, through OSINT and digital forensics work I'd already been doing, and the degree became the tool to go deeper on it, not the other way around.

That ordering matters more than it might seem. A lot of technical work in school ends up shaped by whatever the assignment happens to be that semester. Coming in with an existing direction means the coursework has something real to attach to. A class on network security isn't just an abstract requirement, it's a chance to think about how a small organization's exposed infrastructure actually gets found and exploited. A class on incident response isn't just theory, it's directly relevant to what happens after the kind of alert my tool is built to generate in the first place.

What's already built, and what the program adds

Coming into this program, the OSINT threat intelligence project already has a working pipeline, pulling live data from CISA's Known Exploited Vulnerabilities catalog, matching it against an organization's actual software profile, and turning it into a plain language digest instead of a raw feed dump. It's public, open source, and documented from the first commit.

What I don't have yet, and what I'm hoping this program helps sharpen, is the deeper technical grounding to make the next version of this genuinely better rather than just bigger. Right now the filtering logic is a fairly straightforward matching problem, and the triage logic is intentionally simple, explainable rules rather than anything more sophisticated. That was the right call for a first version built to prove the idea works. Whether it's still the right call once there's real usage data is a question I expect coursework in this program, particularly anything touching network security and infrastructure design at scale, to help answer with more than intuition.

Why this matters beyond the degree itself

CISA's own language is direct about this: small businesses and resource constrained organizations increasingly form the weak point that larger, well defended systems depend on somewhere upstream. That's not a problem a two year degree solves on its own, but it's a problem this specific program, with its focus on networking and infrastructure, is well positioned to help me actually understand at the level required to build something that holds up outside a single developer's laptop.

What comes next

The honest next step for this project isn't more architecture, it's finding a real organization willing to test it against their actual environment instead of synthetic data. That's harder to schedule than writing code, and it's not something a graduate program hands you, it's something I'll be looking for in parallel with classes starting. When that happens, that's the piece worth writing about next, not what the tool is supposed to do, but what happened when someone real actually used it.

For now, orientation's done, classes start this week, and the project keeps running in the background exactly like it has been. I'll keep documenting it as it goes.