The Thing Nobody Tells You About Getting Good at Security

The Thing Nobody Tells You About Getting Good at Security

I’ve been following Daniel Miessler for years. Long enough that some of his ideas have quietly become part of how I think—not because I memorized them, but because they kept proving themselves true in my own work. His latest Unsupervised Learning newsletter hit on something I’ve been thinking about a lot lately, and I wanted to write through it.

The core of what he’s saying isn’t new. He’d be the first to admit that. But it matters more right now than it ever has before.


His main point is this: the best thing you can do in security—whether you’re just starting out or trying to stay relevant—is understand how things actually work. Not at a surface level. At a deep level. The kind of understanding where you’re not just following steps, but you know why each step does what it does and what happens when something goes sideways.

I agree completely. And I say that as someone who spends a lot of her time breaking into systems professionally.

Penetration testing has a way of exposing the difference between memorized knowledge and actual understanding. You can learn a thousand techniques. But if you don’t understand the underlying protocol, the authentication flow, the trust model—the moment the environment is slightly different from your training, you’re stuck. Tools fail. Exploits don’t work as expected. The thing you were counting on isn’t there. What carries you through is mental model, not muscle memory.

That understanding doesn’t come from reading about things. It comes from building them, breaking them, and asking why at every step.


One of the reasons I got into security in the first place is that I wanted to understand systems from the inside out. Not just use them—understand them. What’s the authentication actually doing? Where does trust get established? What assumptions is this software making about the environment it’s running in?

That kind of question-asking is, I think, what Daniel means when he says curiosity is the most important attribute. And I believe that too. Probably more than any other single thing on his list.

Curiosity is what keeps you going when something doesn’t make sense. It’s what makes you read the RFC instead of just the blog post about the RFC. It’s what makes you spin up a test environment and actually poke at something instead of just accepting what you read as true. Curiosity is the reason you keep learning after you know enough to do the job.

I’ve met smart people who lost interest in the details once they felt competent. And I’ve met people who seemed less naturally talented but couldn’t stop themselves from pulling things apart to see how they worked. The second group tends to go further, and they tend to adapt better when things change. Because curiosity builds resilience, not just knowledge.


The part of his newsletter that feels most timely is the AI piece.

We’re at a genuinely strange moment. AI tools can help you write code you don’t fully understand, explain concepts you’ve never studied, and solve problems you haven’t been trained to solve. That’s remarkable. It’s also a little dangerous for someone early in their learning, because it’s easy to mistake fluency for understanding.

I’ve seen this with scripting. Someone uses AI to generate a working payload or a working script, it does the thing, and they move on. But if you ask them to modify it, or explain what it’s doing, or adapt it to a slightly different scenario—there’s nothing there. They got the output without building the model.

The way Daniel puts it is: use AI as a tutor, not a substitute. That framing is exactly right. AI is extraordinary for learning if you’re willing to actually learn. Ask it to explain what’s happening line by line. Ask it why the protocol works the way it does. Ask it to challenge what you think you understand. Build the thing yourself with AI alongside you, not in place of you.

Honestly, having access to a patient, knowledgeable tutor available at any hour is something I would have found incredibly valuable when I was starting out. The advantage isn’t in outsourcing the thinking—it’s in accelerating the learning loop. You can go deeper, faster, if you’re using AI to help you understand rather than to help you skip.


There’s also the visibility piece, which I want to talk about briefly because I think it’s underrated.

Writing helps you learn. Not in a vague, abstract way—writing genuinely forces you to find out what you actually understand versus what you think you understand. Every time I’ve tried to explain something technical in writing, I’ve found gaps I didn’t know were there. That process is valuable. And sharing it publicly means other people can learn from your process, your mistakes, and your questions. It also tends to connect you with people who are thinking about the same things.

I’m aware that starting a blog or writing publicly can feel intimidating—especially in a field where imposter syndrome is practically a rite of passage. But the bar for “useful” is lower than people think. You don’t have to be an expert. You just have to be honest about what you’re figuring out.


Here’s what I keep coming back to: the fundamentals that made someone good at security ten years ago still apply. Understand systems deeply. Ask why. Build things and break things. Stay curious. These things haven’t changed because the field has changed. They’re more important now, not less, because the tools are more powerful and the gaps between people who understand and people who don’t are going to get wider.

AI makes it easier to look like you know things. Deep understanding is what lets you actually know them.

If you’re trying to get into security, or trying to get better at it, my honest advice is: find something you’re curious about and go deeper than feels necessary. Read the source. Build the thing. Break the thing you built. Write about what you figured out. Ask questions without worrying about whether they’re too basic. Repeat that across as many different technologies as you can.

It’s slower than copying and running someone else’s code. It’s also the only way that actually works.


Thanks to Daniel Miessler for continuing to write things worth thinking about. If you’re not reading Unsupervised Learning, you should be.