Saturday Flex: I Was Already Thinking Like a Security Professional — I Just Didn't Know It Yet
- Jul 11
- 5 min read
When I tell people I'm moving from data analytics to cybersecurity, they hear "starting over." I used to hear it that way too. Then I looked at my work—really looked—and realized I'd been speaking the language for years without knowing the dialect.
When people hear I'm moving from data analytics into cybersecurity, they tend to picture a hard reset. New field, new skills, back to the bottom of the ladder. And for a while, I pictured it that way too.
Then I started paying attention to what I'd already been doing — the small, instinctive habits that had nothing to do with a job title. Testing things before I trusted them. Poking at software to see where it broke. Watching a stream of data until something felt off, then chasing that feeling until I found out why. None of it was labeled "security" at the time. That's exactly what it was.
This post is the receipts.
The virtual machine I built before I knew why it mattered
Back around 2013 or 2014, I was a Windows person through and through. There were Macs all over campus at Howard, and I knew that sooner or later I'd have to actually learn macOS instead of walking past those machines. So I did what felt obvious at the time: I looked up how to run a Mac on my Windows computer, and I built a fully functional virtual machine to test-drive the operating system before committing to anything.
I wasn't thinking about attack surfaces or isolation. I just didn't want to buy hardware or break my real setup to learn something new. I wanted a safe, disposable space to experiment in.
It wasn't a one-click install. Running macOS on non-Apple hardware means the virtual machine doesn't behave the way the guides assume it will. I had to enable hardware virtualization in my computer's BIOS, allocate the right amount of CPU cores and RAM without starving my host system, sort out the display resolution so it wasn't stuck in a tiny box, and work through the boot errors that come with running an operating system on hardware it was never meant to touch. There was no help desk. No one sitting next to me. I had a stack of write-ups and forum threads open, none of which matched my exact setup, and I had to figure out which pieces applied to my machine and which didn't — then adjust when they didn't work the first time.
I read, I tried, it failed, I changed one variable, I tried again. Eventually it booted clean, fully functional. And I'd done it myself.
That loop — research, isolate the variable, test, adjust, repeat — is the entire job. It's what troubleshooting a failed pipeline looks like, and it's what working an incident looks like too.
That's sandboxing. Running untrusted or unfamiliar code in an isolated environment so that whatever happens inside stays inside. Security teams stand up VMs to detonate suspicious files and study malware without risking the host. I was doing a gentler version of the same thing — contain first, explore second — years before I had the vocabulary for it.
While I was at it, I was allocating CPU and memory to that virtual machine, deciding how much of my real system to hand over to the fake one. That's resource partitioning. That's a baby step into systems administration.
Beta Tester of the Month, and 321 tests later
I started beta testing apps in 2013. Somewhere in there — May 2015 — I was named Beta Tester of the Month on the platform I worked through. There was even a write-up about it at the time. I don't have the link anymore, and I've mentioned it before on my older, weather-focused site, but it happened, and it meant something to me.
What was I actually doing in those tests? Installing pre-release software, using it deliberately in ways the developer might not have anticipated, finding where it cracked, and writing up clear, reproducible reports so someone could fix it. The reports were structured, every time.
A typical one asked me to rate the app, describe what worked and what didn't, note how far I'd gotten, specify the environment — right down to which language I ran it in — and then the question that mattered most: Did you encounter any bugs? If yes, what was the bug?
That last field is the whole game. Reproduce it, describe it precisely, capture the conditions. To this day I've logged over 320 tests, and I still beta test on Android and Apple using the devices I don't rely on day to day.
I learned why you use the spare devices the hard way. I once installed a buggy build on my MacBook Air and bricked it. But — and this is the part that matters — I found a fix online, reinstalled a stable version, and brought it back. I didn't panic. I diagnosed, researched, and recovered.
Hunting for the specific conditions that make software fail, then documenting them so they can be remediated, is vulnerability assessment. Structured, reproducible bug reports are, functionally, findings. And the "test on the device you can afford to lose" instinct? That's isolating your blast radius. I just called it common sense.
Ten years of watching for the thing that doesn't belong
Here's the part that ties directly back to the day job.
For over a decade in data analytics, my work has been anomaly detection. In healthcare analytics, that means noticing when a claim, a pattern, or a trend deviates from what the data should look like — and knowing that the deviation is the story. Before that, in atmospheric science, I was reading weather data for the signal buried in the noise: the pressure drop, the pattern break, the early signature of a system forming before it announced itself.
Storms don't send a calendar invite. You learn to spot them from small anomalies in the data, hours ahead.
That is threat hunting. A SOC analyst sits in front of network traffic and asks the same question I've been asking my whole career: what here doesn't belong, and what is it trying to tell me? Beaconing at a suspiciously regular cadence, a host suddenly sweeping the network, a login from somewhere it shouldn't be — those are anomalies in a different dataset. Same instinct. Different domain.
The section that named it for me
The Home Lab I Didn't Know I Had
In cybersecurity, people talk about your "home lab" like it's a rite of passage — a rack of servers humming in a spare room, a wall of blinking lights, a serious hardware investment.
I want to gently push back on that, because it kept me feeling like an outsider longer than it should have.
A home lab isn't the hardware. It's the habit. It's the practice of building isolated environments, deliberately breaking things to understand them, and testing before you trust. By that definition, I'd been running a home lab for years and never once called it that.
No rack of servers required. If you have a spare device, some curiosity, and a habit of testing before trusting, you already have a home lab. You might just need the language.
If reading this makes you want to build one on purpose this time — deliberately, with the right free tools and without risking your daily driver — I'm putting together a beginner's guide to doing exactly that. No server rack, no big spend. More on that soon.
The Reframe
I spent a while thinking the transition into security meant starting over. It didn't. The sandboxing, the vulnerability assessment, the recovery-under-pressure, the years of anomaly detection — I'd been building the instincts the whole time. What I was missing wasn't the skill. It was the word for the skill.
If you're a data analyst, a QA tester, a weather nerd, or just the person in your house who reads the manual and pokes at the settings — you might be further along than you think, too.
I wasn't starting from zero.
I was already there.
I just needed the language.
Comments