Written by: Joseph Sarkisian, OSCP, GWAPT
I am lucky to have an increasing number of larger clients for my penetration testing engagements. While it is always enjoyable to work with smaller healthcare companies, banks, credit unions, and others, larger clients may have more advanced security controls in place given their available resources and culture. This is a challenge I always look forward to.
This also brings with it a particularly pervasive challenge completely unrelated to the technical aspects of the work: bureaucracy.
We hear the following from these new clients, typically at the beginning and end of the engagement:
- But we let you in.
- That’s not a realistic scenario.
- Our MSSP would have stopped you.
- Why do you need administrative credentials for a pen test? (More on this one below.)
- We don’t feel comfortable providing you with X,Y,Z evidence.
- This report does not adequately reflect our environment.
- Yeah, but we’re tracking that issue.
- Our report was clean last year.
- Why didn’t the previous vendor find this?
The list goes on, but you get the point.
As we go through these questions either during a scope call or draft report meeting, something always seems to rise to the top as the “root cause” of these statements:
Whoever was hired to do this last time failed to adequately explain why we do what we do.
This is not to say we are perfect – everyone makes mistakes, communication breaks down, etc. We are all only human after all. But selling a vulnerability scan as a penetration test, a penetration test as a red team, not having scope calls early enough before an engagement to build rapport, not explaining the difference between a vulnerability assessment, a pen test, a red team, etc., is hurting the client.
If we ask for administrative credentials for a vulnerability assessment, and are told that’s cheating, then someone has sold them a fake bill of goods in the past. We would never ask for administrative credentials for a pen test, but clearly someone down the line conflated a vuln assessment with a pen test, thus the confusion.
This snowballing of miscommunication and/or in the worst case, outright snake oil salesmanship of prior engagements, puts those who want to do the job right in a tough spot, since there will likely be a laundry list of low-hanging findings for us to expose. This understandably frustrates the client since they assumed the somewhat clean reports they’d been getting until now from previous vendors meant they were a near-impenetrable fortress. Now we must thread the needle of not belittling a previous vendor while also explaining that the risk we have unearthed must be taken seriously.
The information security technical services industry must get better at understanding what clients need. Selling a red team to a small community bank by playing off their predilection for buzzwords is both absurd and likely not going to add any value. Intentionally selling a vuln scan as a pen test is outright fraud. There are more examples, but you get the idea.
Something I have pushed hard for is getting a senior pen tester on the initial pre-sales call to ensure the most accurate, value-driven engagement possible. It takes 30 minutes of their time and we have been told for a fact that at least one large client chose us over larger security companies because we had an actual tester on the line and formed a relationship from the get-go.
Let’s all get better at understanding our own strengths as testers, our capabilities as teams, and the intricacies of the needs of clients across industries. Maybe then we can chip away at the laundry list of uncomfortable conversation starters.
