The focus of a penetration test usually revolves around the identification of vulnerabilities, their exploitation and the estimation of potential damages. “Vulnerability” is a flexible term in that regard: Depending on the scope of the project, vulnerabilities can be of a specific technical nature, or of a broader, generic nature.

Corporate LANs are a good example. Vulnerabilities observed here are often of the more generic, systemic type: Sluggish patch management can lead to the prolonged exploitability of vulnerabilities, that have already been patched by the vendor. Missing or ineffective network surveillance leads to an attack remaining undetected for a prolonged period of time and can cause additional damages. Tests of web applications, on the other side, will usually yield more traditional findings: Cross Site Scripting and SQL Injection due to the lack of proper input validation. The lack of security headers, improper flags on session cookies and the lack of proper transport encryption.

These differences play a crucial role when it comes to the reporting of the performed tests. Usually, the benefit of having found these flaws, as measures by the customer, depends heavily on the consistency, the precision and the level of detail of the report. It is everything but rare that there is a sense of astonishment that about a third of the total effort in a penetration test is spent on reporting.

What eludes a lot of aspiring penetration testers during their first weeks on the job, is the necessity of giving adequate guidance and recommendations regarding the mitigation, or even complete elimination, of vulnerabilities. A penetration does not only strive to identify, but eliminate vulnerabilities altogether, where possible.

The aforementioned variety of flaws, from technical mishaps to conceptual shortcomings weights even heavier here. Specific vulnerabilities are often easily addressed: A recommendation to change a line of code, to add a configuration setting, or to disable an obsolete service. But even here, this is not a consistent situation. In complex web applications, multiple vulnerabilities of a certain type often indicate deeper set quality problems within the software, which should be addressed in a broader war. But generally, issuing clear recommendations is easier in these scenarios.

But what happens, when the identified vulnerabilities cannot be addressed with one or two specific measures? What if the recommendation should read Improve patch management or or Implement missing incident response processes?

These generic countermeasures are entirely valid, but often leave customers scratching their heads: Building an internal CERT, a reliable Secure Software Development Lifecycle (SDLC), the consistent detection of irregular user behavior – all of these things are valid recommendations that cannot be implemented within days or weeks but require a deeper commitment from both technical personnel and top management alike.

Penetration testers should communicate openly in that regard: Oversimplification of complex countermeasures requiring high efforts are not benefiting anyone, but usually lead to confusion and distorted expectations. A clear, honest statement explaining that certain problems cannot be dealt with in a single table cell labeled countermeasures, but need to be addressed specifically within the environment of the affected organization contributes significantly to the goal-oriented and constructive tackling of the problem. This does not necessary mean that the, usually demanded, short term measures should not be pursued as well: They play an important role in preventing the short-term exploitation by real antagonists while a more persistent solution is being drafted and implemented.

It is often appropriate, to let specialists chime in on complex mitigation plans. In our specific example, here at scip AG, it is all but unheard of to consult the colleagues of the blue team, who are entirely focussing on defensive security to discuss the proper coordination and prioritization of countermeasures, often in a dedicated follow-up project. At the end of the day, the goal of every penetration test should be to bring an improvement to the customer’s environment: To drag vulnerabilities out into the light and address them in a constructive and meaningful manner.

About the Author

Stefan Friedli is a well-known face among the Infosec Community. As a speaker at international conferences, co-founder of the Penetration Testing Execution Standard (PTES) as well as a board member of the Swiss DEFCON groups chapters, he still contributes to push the community and the industry forward.