This blog post is intended to help organizations understand the mentality and drivers behind pentesting and to help them recognize that we (pentesters, red teamers, etc.) exist to HELP. We work to find security weaknesses or vulnerabilities, so you can improve the overall security of your companies, systems, and products – rather than an antagonist or malicious attacker.
Long, long ago, in a land far away, the author of this blog post was a professional software engineer. There were many projects I worked on with significant personal investment and which I was deeply proud of. Most software projects are hard work; every software engineer or developer is proud of the products and of their efforts, which means they can become defensive of them.
There is some element of personal pride in a project; if it’s broken or has problems, some developers take that as a reflection on their ability. Imposter syndrome is rampant everywhere in tech, especially in the development field. No one wants to hear their baby is ugly.
To compound matters, developers are often overworked and over-scrutinized. They’re constantly dealing with swelling backlogs full of excessive and unreasonable feature requests and irrelevant or invalid bug reports. Not to mention, constant continuing education requirements to keep up with the latest technology they need to use in their areas of expertise.
Enter the Information Security team. Security teams come in and impose unwanted fixes, compliance requirements, and rules on top of a developer’s already enormous workload. They make demands that push back planned deadlines and sometimes even result in canceled projects due to seemingly arbitrary requests.
No one wants some outsider coming in, ordering them about and ruining their best-laid plans by force. This can result in a desire to do the minimum to “check the box” to pass whatever audit happens to be afflicting them at the time. This is a completely understandable reaction; unfortunately, it can cause untold damage in the long run.
We are here to offer constructive criticism, not to critique.
Let’s take a look from the pentester’s perspective. Whether on an internal team or an external consultancy, pentesters frequently encounter resistance or open hostility. Working on the other side of the situation as a pentester, I’ve experienced many things in this vein. From development teams just ignoring any emails trying to coordinate the pentest effort, to open and active hostile actions including shutting off known-vulnerable features and technology until the pentest is complete. Some teams have even actively blocked requests during a test to try and prevent evidence collection or have applied organizational political pressure to avoid including findings in reports.
While these reactions are in some way understandable, given the pressure on teams to avoid or fix security issues, they have a fatal flaw: they result in covering up actual security problems. Aside from being fundamentally unethical, these sorts of behaviors result in false-negative reports, insinuating that problems don’t exist.
However, problems or vulnerabilities do exist (even in the best companies, products, or systems) and given enough time, the bad guys will find them. Hiding problems doesn’t make them go away and the consequences of these actions can be quite dire, depending on the scenario. We aim to help you find and remediate weaknesses before they become even bigger issues or the bad guys do some damage.
An additional side-effect is that these actions can also result in negative relationships between security and development teams. This is why I wanted to write this blog post to demonstrate that pentesters are, in essence, a developer’s sparring partner.
We exist to challenge you and play the “bad guy”- the robber to your cop. We “fight” developers so that they can prepare with “training wheels” before they’re actually challenged by malicious actors in real life. Pentesters don’t go for the kill, but provide opportunities to improve. We identify and exploit weaknesses so developers can build up defenses around those weaknesses.
As pentesters and red teamers, our job is to prepare development and support teams for real-world threats. We are your sparring partner. An average boxer needs to train hard to succeed against every adversary. You don’t go from the local boxing club to a championship match with Iron Mike without preparation, just like you don’t want to take on advanced threat actors without having security assessments or experience dealing with threats. The difference is that real threat actors decide when the match is fought, so it’s better to be prepared earlier rather than later.
Experienced pentesters understand the challenges faced by companies and their development and infrastructure teams. We aim to be effective “sparring partners” to enhance security and facilitate positive change within their customer organizations.
Even though we pretend to be threat actors, we’re not ill-meaning. Pentesters are not here to get you fired, in trouble, or your project cancelled: quite the opposite. Pentesters exist to help find problems so that they can be fixed and prevent the real bad actors from succeeding. We want developers to fix things; we want them to make life harder for us. Because if it’s hard for us to exploit something, it’s hard for the bad guys as well.
One final thing to mention – while pentesters are empathetic to business needs, it’s important to take into account the tongue-in-cheek security quote: “Bad guys don’t care if your system is out of scope”. But we do, that’s why you need our help. The more systems and software that can be evaluated, the safer we all are. We can work together to keep everyone safe and prevent security incidents.