A Journey to Friendlier Pentesting
September 26, 2022
Separate Ways, but Not Worlds Apart: A Journey to Friendlier Pentesting was Written By: Tyler Fordham, Senior Principal at Dark Wolf Solutions, LLC
This is a guest blog, NSTXL takes no ownership of the ideas presented. It is intended to stimulate conversation and discussion within the community.
Separate Ways, but Not Worlds Apart: A Journey to Friendlier Pentesting
As an offensive security professional, one can often face unique challenges compared to colleagues in the rest of the information technology space. After all, why wouldn’t you – hacking is scary stuff that you see the bad guys and anti-heroes do in movies, right?! While that trope seems silly to type out, particularly for a reader in the know, the reality is that your average person’s reaction is not far from that exact insinuation. Any penetration tester foolish enough to talk about their job to family or strangers has been asked if they could hack phones, Facebook accounts and the like by those without knowledge of the discipline. From personal experience, they don’t stop believin’ even when you tell them it’s not that simple.
While your fellows in the computer industry will generally not be that out of touch, your everyman’s perception of “hacking” illustrates an important point to consider professionally; that a lack of information can cause people to misunderstand the role of ethical hacking. From the perspective of a penetration tester, this is a pertinent thing to recognize, because these impressions made by media or prior negative experiences can create an adversarial relationship before you ever interact. To invoke some of the most common:
- System Administrator: Wild and free hackers diving into a network that I built and maintain feels like a lose-lose for me – me and my team have tons of preparation ahead of us and will need to scramble to fix issues after they’re done.
- Developer: I’ve written my code in accordance with my organization’s needs and development standards, and my commits pass every pipeline security check, so why do hackers need to double check my work? Having to fix underlying issues in our code base will add tons of tech debt…
- System Owner: Why do they need access from the inside? This assessment is only going to result in my bosses criticizing me and my team for any issue they uncover. We’re in compliance regulations and our authorizing official or CISO approved our product, so why do we need another layer of scrutiny? I’ll be alright without you!
Here’s the honest reality – in many cases, none of these thoughts are really incorrect! There’s a significant difference between a communicative, improvement-driven penetration test versus a results-driven engagement focused on getting as many “wins” as possible. While these two things can happen effectively in concert, too often are offensive security assessments only the latter. While going full bore with no communication has its time and place (an internal red team assessment, for example), this engagement style can sour relationships with stakeholders and validate some of the fears mentioned above.
On the other hand, a capable and mature offensive security team has the capability to gain and keep the trust of every stakeholder described above when an appropriately light touch is used. The guiding principle to keep in mind is that penetration testing someone’s system is like holding their baby; you’re being trusted to be hands on with something very important to them that’s taken sweat and tears to create. Following the childcare analogy, making it clear that you’re on someone’s side and know what you’re doing is the best way to assuage their fears when you come to them with open arms.
In the same way that conducting a penetration test is an iterative, evolving process, making an ally of your testees is a wheel that keeps on turning from initial interactions to the latest remediation testing. Let’s cover what that looks like throughout the length of an engagement.
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 email@example.com.
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!