Builder vs. Breaker - Do developers make good pen testers & vice versa

Question

Do developers necessarily make good penetration testers & vice versa?

The reason I ask is that I find I have much more of a knack for figuring out how an existing piece of software works and can be manipulated than actually designing and developing things myself.

I can program and I'd say I have an intermediate level of expertise but I have a hard time going from idea to finished project. I'm much more motivated and feel like I'm much more in a mental state of flow when trying to reverse engineer how something I have in front of me is working.

I think it's kind of the same idea as a writer or painter who talks about that anxiety of looking at a blank page. I feel like when working backwards from an existing piece of software there are constraints and context already there that gives me something to latch onto mentally. Whereas when developing software that 'blank page' and all the possible ways of designing and implementing something make my mind spin up and analyze every possibility.

I've seen this discussed in security circles as builders vs. breakers. The idea that some people are just wired more for building stuff with the traits that favor that and others for pointing out what's wrong with it.

In your experience is this a real thing or just a false dichotomy?

How essential are development skills for penetration testing?

I definitely really enjoy learning about how things are implemented and I'm not shy to read the source to figure it out. I like writing smaller scripts and tools that have a specific purpose but big full on programming projects with a lot of architecture abstractions I find I often end up losing interest and momentum.

How much should I let this bother me if my goal is pen testing rather than an actual development position?

Answer 1

Generally speaking, to be a good pentester you have to master some of the skills that are required to be a good programmer. Solid development experience about possible programming mistakes is very helpful, because a lot of pentesting is about finding corner cases that the programmer did not think of -- i.e., bugs. This goes both way: a good developer should have some pentesting skills because making robust code implies taking care of anomalous conditions, the kind of things that the pentester (and potential attackers) try hard to trigger.

There are facets of software development which do not directly help with pentesting; in particular structural abilities like knowing how to design a simple, slick and extensible API, or being good at documenting code.

There are facets of pentesting which do not directly help with development, e.g. everything which amounts to social engineering.

As for psychological traits, I'd say that it is not really a question of building vs breaking; at least not about being good at building or breaking. It is more about having fun at building or breaking. Pentesting can be frustrating, especially if you are on the "creative" side of people, because you spend all day dealing with poorly written code and you know you could do much better, but that's not your job. On the other hand, a successful intrusion into a seemingly robust server is intellectually rewarding; pentesting is a battle of wits, where you fight against the mind of the developers, while development is a battle against the laws of physics, which can be daunting at times. Development or pentesting, you can do it for a long time only if you find the activity pleasurable.

Alexander the Great was a developer; Machiavelli was a pentester. Genghis Khan was both.

Answer 2

The Bear has already given a great answer, but let me attempt to answer this from the perspective of a pentester who moonlights as a developer.

There are multiple aspects to penetration testing. I know some pentesters that are absolutely amazing at system level and network level security, while there are others who are primarily focused on Application Security. In my experience, the former usually come from a desktop support/network engineer/systems administrator background. The latter, more often than not, come from a development background.* That, to me, has been telling in many ways. As stated in the other answer, a penetration tester with a development background is usually good at finding flaws in software, especially if they have spent a long time in the industry - it just takes some training to think like a hacker to find security flaws in code and applications. These guys are also going to be good at reviewing code for security issues, and coming up with elegant fixes for these flaws that an otherwise inexperienced developer might not be able to implement.

The other advantage that application security people, and in general, penetration testers have with a development background is the ability to develop their own tools when they're testing code. At some point, you're going to run out of off-the-shelf tools to do your job, and you're going to either hack someone's code, or write your own code to do what you want. While I've seen people with basic python skills do this, the more elegant and beautifully done tools have come from people with a classic development background.

That said, I have also seen some exploit developers and reverse engineers who - while good at writing code - really don't want to do it. But they are amazing at what they do, and their knowledge as a developer makes it easier for them to reverse code, analyze malware, or even write their own malware.

At the end of the day, in my personal experience, knowing how to write and read code is of paramount importance, especially if you're interested in getting into application security. Understanding how applications work has definitely made it easier for me to break applications.

To summarize, if you are good at writing code, you have an advantage over a lot of people in the field - a lot of good application security guys I know absolutely suck at writing good code. If you're more interested in hacking other applications to do what you want them to do, keep doing it. If writing code from a blank paper stage scares you...well, try to work through it and gain confidence, because it's not hard once you get some experience. It's all a learning process, so keep learning!