The Security Pigeon

The Security Pigeon

I spent the early part of my career getting paid to break into things. Energy infrastructure, manufacturing plants, financial systems. If it had a network and someone was worried about it, I was probably poking at it. It was, without question, the best education I could have gotten. You see the best security programs in the world. You also see the worst. You find out very quickly that the gap between them has almost nothing to do with the technology stack and almost everything to do with whether anyone in the building actually cares.

It was a brutal lifestyle, especially at the time. The culture of offensive security in the early days was not exactly known for its warmth or its work-life balance, but if you could handle it, what you got in return was a crash course in best practices. I watched smart people build elaborate defenses around the wrong things. I watched organizations spend enormous amounts of money on tools that no one monitored. I walked into air-gapped manufacturing environments through security devices that were inadvertently bridging the gap their own vendors had installed. I found my way into SCADA systems controlling building safety and environmental controls through paths that should not have existed, and often did not exist on paper. Then, I went back to the same clients the following year and found the same problems.

That is the thing nobody tells you about penetration testing as a career. It is structurally designed to not fix anything. You come in, you find the holes, you write it up, you leave. The next year, you come back, the holes are still there, you write it up again. Again and again, it felt like I could just change the date on the previous year’s report and hand it back to them. I had done everything right. Nothing had changed. That is when I started referring to myself as a security pigeon. Fly in, sh*t all over everything, fly out. Repeat annually. Bill accordingly.

I got tired of it. Not of the work itself. I still think breaking things is one of the best ways to understand how to build them. I got tired of the part where nothing got better. If I was spending every engagement documenting the same failure modes at the same organizations, the problem was not that the findings were unclear. The problem was that nobody on the other side had the tools, the budget, or the organizational mandate to do anything about them. Writing a better report was not going to solve that. So, I switched sides. I moved into vulnerability management because I wanted to build the programs that made my old findings stop being findings. And I found, almost immediately, that the hardest part of that job had nothing to do with the technical work. It was convincing the organization to fund it.

This is where I parted ways with most of my peers in a pretty significant way. At the time, the loud consensus in the security community was that regulatory compliance was ruining the industry. Regulations were too prescriptive, they set the bar too low, they reduced complex security decisions to checkbox exercises. People were giving talks at Blackhat about how compliance was the enemy of actual security. I decided that they were all very wrong. They were just looking at it the same way as most organizations, as a checklist of the only things you needed to do to be secure. Compliance is not security. You can be compliant and not be secure. However, if you are secure, and you have a mature security program governed by a comprehensive set of policies, you will always be compliant.

Compliance frameworks, whatever their limitations, do something that pure security advocacy almost never manages to do. They create financial and legal consequences for inaction. If you can build a security program that is also a compliance program, you have just converted a cost center with no obvious ROI into a legal obligation with repercussions for ignoring it. That is not a compromise. That is a budget lever, and I have leveraged the hell out of that.

The insight that took longer to arrive was the one that eventually moved me into product security. Vulnerability management was better than penetration testing in the sense that I was fixing things rather than just documenting them. I finally realized, though, that I was still operating downstream of the decisions that introduced the vulnerabilities in the first place. The architecture choices, the design decisions, the shortcuts taken under schedule pressure. By the time those surfaced in a scan or an assessment, the cost of fixing them was already enormous.

Product security is where you get to be in the room before any of that happens. It is where you can stop a vulnerability from existing rather than racing to remediate it after the fact. That is not a subtle difference. It is the difference between building a door and picking a lock. I got tired of picking locks. I’m here to build the bunker.