Why Communication is Your Most Undervalued Skill as a Pentester

Throughout my career, I’ve done a lot of penetration tests. You need to know your way around a computer to be good at it. Many technical skills are involved, whether it’s writing some script, developing an exploit, or using tools like Burp or Metasploit. A big part of every penetration test is communicating effectively throughout the engagement. This article will cover three reasons why communication skills are probably the most undervalued thing in your tool belt as a pen tester.

Scoping and planning

Scoping is a critical part of the penetration testing process. It lays the foundation for the rest of the engagement. It also significantly impacts whether the test is a success or a failure. Because of this, it’s essential that all parties involved in the process are on the same page and fully understand the intended scope, how things work, the objectives, the drivers for the test, and the expectations.

An often neglected area during scoping that a tester can leverage is beginning to ask questions and think like a threat modeler. Building out a threat model of the system and assessing and validating assumptions through the penetration test can be a powerful complement to whatever mythology is used.

There are several reasons why communication is so important during this phase.

• Effective communication helps ensure that the test's scope is clearly defined and understood by all parties involved. This includes determining the specific systems, networks, URLs, API endpoints, or functionality that will be tested. This includes any limitations or exclusions. Without clear communication, misunderstandings or discrepancies about what is and is not included in the scope may lead to confusion and potentially flawed results. This could also lead to perceptions of an incomplete test or, worse, something breaking unintentionally and disrupting value streams that the target of the pentest is supporting.
• Good communication helps to establish trust and cooperation between the penetration tester and the client. The client is entrusting the tester with access to their systems and potentially sensitive information, so it is essential that they feel comfortable and confident in the tester's abilities and intentions. They should also be confident about the results they will get and that their objectives will be met. By clearly explaining the test's process, objectives, and expectations, the tester can build trust and establish a positive working relationship with the client.
• Effective communication is necessary to identify and address any potential risks or concerns. Evaluating potential risks associated with the test is crucial at this stage before anything happens. Risks might be downtime, corrupted data, or users receiving communications in error. By openly discussing and addressing these risks, the tester and client can work together to mitigate them and ensure that the test is conducted safely and securely. As the saying goes, an ounce of prevention equals a pound of cure.
• Ensuring that the tester has the necessary access and permissions to conduct the test is evident when you think about it, but it’s necessary. Nobody wants to waste time, at least those paying for the test. The tester must coordinate with the client to ensure they have the credentials and access to the tested systems.
• Agreeing early on regarding any particular reporting processes needed will save time. This might mean report templates, mapping findings to CWE, using CVSS to risk rank, or something else entirely. This shouldn’t always be up to the tester.

Updates and engagement throughout

The range for communication at this stage is pretty wide. Communication is crucial when critical issues are found during the test. The goal of a test is to help the client reduce and manage their risk. By taking this step, you’re giving the client the time to take action and fix the issue. A fix might mean a code change, a patch, a virtual patch (like a WAF rule), or whatever is necessary.

I believe it needs to go beyond that, though. Communication throughout the test helps on several fronts:

• Maintaining high levels of trust between the tester and the client, knowing what is going on, what is being tested, etc.
• Communicating more regularly establishes a feedback loop similar to any other collaboration. When an issue or a question arises, it can be addressed much more smoothly.
• The tester can build on their initial questions asked during scoping as they learn more through testing. Continue to build and develop the threat model and contextualize the test.

Reporting

If you were to ask 100 pentesters what their least favorite part of the job is, my hunch is 90% or more of them would say reporting. The writing, the detail, the back-and-forth quality control reviews, and then the read-out. These things take time away from the creative work of testing and exploit development, which is seen as much more intellectually engaging and challenging.

Ultimately, pentesting is about helping a client drive down risk. In this context, it’s mainly about fixing vulnerabilities. A well-written report can help the client prioritize their efforts and allocate resources effectively to do just that. Address the most pressing issues and drive risk down. In this way, the report serves as a roadmap for the client to follow to improve the security of their systems.

A tester could conduct the best assessment known to mankind; things are unlikely to change if they neglect this stage. If things don’t change, we’re not making the impact we’re there to provide. A poorly written report or one was haphazardly thrown together to “get it done” does a disservice to otherwise excellent work.

I recommend a few key elements in the reports you write up:

• First, the report should provide a clear and concise executive summary. At this stage, you should focus on summarizing the essential findings and recommendations of the test. I like to frame this from the business risk perspective, with context discussed during the scoping stage. This summary should be written in language that is easy for non-technical readers to understand and should highlight the most significant vulnerabilities that were found.
• The report should provide a detailed description of the testing process. This should break down the scope of the test, the tools and techniques used, and any limitations or constraints encountered. This particular part of the report is about confidence building in the process for anyone who receives and reads the report. Remember that the client is likely using this penetration test to meet some other goal they have.
• This one should be obvious, but the report should include a detailed breakdown of the vulnerabilities found throughout the test. This means including a description of each vulnerability, the risk it poses, and the recommendation for how to fix it. To the extent that it’s possible to contextualize the risk of a given vulnerability, I think it’s work that can pay dividends for the client. For example, including additional details about how two vulnerabilities can be worked together in a broader exploit context.
• Remediation details are also an area where the tester should strive to contextualize as much as possible. The people reading this part of the report are likely developers or sysadmins. Providing generic advice on how to address a SQL injection vulnerability isn’t as useful as a more personalized explanation that considers the client’s tech stack. This is again where scoping details and the context gained throughout the test should be leveraged. Including different layers of remediation, guidance can also be helpful in case one particular approach isn’t possible.
• Appendices with any additional details or supporting materials can be useful if there are any. Examples might include diagrams, code samples, log files, or tool output. This can be referenced throughout the report without bogging the reader down with too much detail.

Writing an excellent report is a lot of work, but it’s well worth it for the client. Remember to use clear and straightforward language. Keep things clean with clear headings and sections. Use clean visuals if they’re being included. The report is what you leave behind, so make it worthwhile.

Concluding thoughts

Hacking and writing code and tearing through an environment to domain administrator privileges is fun. These things are oftentimes remarked as the hallmark of a good penetration tester. This article covered three reasons why I believe communication is one of the most underrated skills in a tester’s arsenal. If you improve here, you will improve as a security professional. You will provide more value. You will understand more of what the client needs and be better positioned to bridge the gap between your skills and their needs.