Our two friends above help illustrate the differences between an adversarial and a friendly pentest!
Any Way You Want It: Scoping, Starting and Solidarity
The kickoff of a penetration test can be a stressful time for the client team having their system tested. Not only are their schedules interrupted, but they might feel like they have targets on their backs based on what’s found during the event. This dynamic can result in penetration testers being given limited accesses, or might even lead certain known vulnerable resources to be hidden before an engagement.
Given the above, one mark of a successful penetration testing team, as odd as this sounds, is empathy! If you understand why your team might be viewed under a lens of suspicion by the folks you’re faithfully supporting, you can make proactive choices to not only make everyone’s lives easier, but ensure that you’re able to conduct the most valuable test possible.
Make it clear that the penetration test is NOT going to be an adversarial activity! Clients may expect that a team of even ethical hackers will be going in for as many “wins” as possible, and making it clear that you’re professionals there to help them goes a long way.
Explain that communication between your team and theirs is going to be an ongoing part of the engagement, and that they’ll be the first to know when major issues are identified. In fact, inform the client that you’ll communicate major vulnerabilities as soon as they’re discovered. Not only is this a best practice for nipping big issues in the bud, but keeping technical stakeholders in the loop on findings lets them get ahead on remediation planning.
Make it clear WHY you want and/or need certain accesses, to include accounts, routes, etc. and WHAT you plan to do, both verbally and in a defined plan. You shouldn’t expect everyone else to know the difference between things like a white and black box pentest, and the more you can help clients understand, the more likely they’ll provide access that your team needs.
Lights: Illuminating Your Operations
When things have officially kicked off, the life of a technical stakeholder can be filled with anxiety. Not only the young phases of a test are worrisome - they’re waiting around the entire time ready to have something go down or for the security operations center to stress out over a perceived incident. You’ve got the tools, however, to make this a less stressful experience for the concerned client.
When you identify a vulnerability that could present a significant and immediate risk to the system you’re assessing, stop what you’re doing and notify your point of contact(s)! This should be explicitly written into nearly any rules of engagement document, and is incredibly important. You may be encouraged to keep digging in some circumstances, but the biggest issues will often require significant planning to solve, so sooner notification is better regardless of the next steps that arise.
In general, keep your system administrators in the loop! Situations like gray-box testing will generally involve communicating with the stakeholders who dole out accounts and accesses, but if you’ve established earlier rapport, it doesn’t need to stop there. System stakeholders who have bought into the security benefits of a penetration test can be a great source for obtaining additional information and confirming or denying the intended functionality of a system being tested.
Above all else, just keep an open line. Even non-technical stakeholders can be pensive when a penetration test is ongoing, so brief status updates, emails and phone calls can go a long way towards removing the shroud of mystery from a test. If they’ve got a Slack or Teams channel, see if you can be on it! Oftentimes, this level of direct communication can be the best way to keep expectations in check with a client and maintain their trust in the lead up to an outbrief.
The Party’s Over: Closing Out a Test
The climax to a penetration test’s story can be the most stressful part for a worried developer or administrator. In an organization not used to or wary of penetration tests, the end of a security assessment can be a time where results are viewed solely through a critical lens and the question of who’s crying now changes with every vulnerability detailed. In a more healthy setting, however, this does not have to be the case!
Early into an outbrief, make it clear when and where you received help, and from who. Leading off with thanking parties on a call who enabled a penetration test eases tension and builds immediate goodwill, and most importantly makes sure that people who took time from their jobs to help with the event are recognized. This step can help improve collaboration and reduce perceived criticism in situations where you have many and/or serious issues to report.
Keep vulnerabilities in context and don’t oversell risk. A penetration test is about the system and its owning organization, and not the pentesters - it’s a recipe for failure if you let personal excitement over a complicated finding overshadow the collected explanation of why it’s important and how it’s fixed. Keep in mind that, ultimately, everything you report constitutes extra work and risk for the audience to consider.
Explicitly call out a system’s strengths! From both a technical understanding and relationship building perspective, it’s important to let clients know what you could NOT break, bypass or modify. Recognizing that even a test that produced many findings has its bright spots can help to secure a positive attitude for stakeholders towards penetration testing.
Afterthoughts: After All These Years
I’ve seen a wide range of penetration tests of every variety in my time with Dark Wolf, and it isn’t an understatement to say that more often, a customer’s attitude afterwards was most influenced by the soft skills detailed above than the actual technical parts of the assessment. While not every hacker is a fan of dealing in pleasantries, it’s helpful to keep in mind that you’re giving yourself a force multiplier for the success of your engagement when you take these steps. If you make an early enemy of the engineer who’s opening up routes for you to get in, you probably won’t get set up with quite the robust accesses you would have otherwise.
In all actuality, much of what’s described here is not far off from the hacker skill set of social engineering. While I wouldn’t recommend that you actually social engineer a client, understanding how other people work and how to get the best out of everyone in a collaborative professional setting is a worthwhile endeavor. When it comes to setting yourself up for a successful and hassle free pentest, be good to yourself by being good to others. In the meantime, if you’ve been on the negative side of this process from either end and want to chat about making it better, shoot me an email at firstname.lastname@example.org.
Sidenote: Ask(ing) The Lonely
If you can identify every Journey reference in this blog, then… congratulations, you occupy a small cross-section of the venn diagram of information security professionals and classic rock fans!