I did not know I was learning security.

In high school, computers were one of the few things I could spend hours with without getting bored.

Our computer lab was different from the rest of the school. It was where you could use a computer, access the internet, and explore things that were difficult to get from a textbook.

Most of the time, though, the machines were locked down.

Our teacher had restricted administrator access, so students could not install whatever they wanted. Games were blocked. Applications were restricted. The computers were set up to do what they were supposed to do and nothing more.

I understood why.

I was also curious enough to wonder what would happen if those restrictions were not there.

Eventually, I found a way around them.

Suddenly, the computer behaved differently.

I could install things. Change settings. Experiment. Try software I had only read about. If I wanted to understand something, I could actually explore it instead of stopping at the page in a book.

At the time, I did not know the words vulnerability, privilege escalation, access control, or security boundary.

I was just a student who really liked computers.

But looking back, that experience changed the way I thought about technology. I had discovered something that has stayed with me ever since.

A system does exactly what its rules and configuration allow it to do, not necessarily what its owner intended.

That idea followed me into IT.

When I started working with systems and infrastructure, I began seeing the same principle in much more complicated environments.

• A user cannot log in. Why?
• A server is unreachable. Where does the connection actually stop?
• An application is behaving strangely. Is the application really the problem?
• A system is considered secure. What has actually been exposed?

The questions became more interesting as the systems became more complicated.

I moved from simply using computers to understanding the systems behind them. That took me through Windows and Linux administration, Active Directory, networking, firewalls, virtualization, web applications, and security research.

Today, when I investigate a system, I still approach it with much of the same curiosity I had in that school computer lab.

I want to know how it works.

I want to know what its rules are.

I want to know what happens when one of those rules is misunderstood, misconfigured, or bypassed.

And I want to understand the consequences before deciding what should be changed.

That is probably the simplest explanation of why I ended up working across infrastructure and security.

I never started with a plan to become a security researcher.

I started with a computer, a lot of curiosity, and a question: what is this thing actually allowing me to do?

I am still asking that question.