Recently I came across a tweet by @CristiVlad25 asking about what you should write in a pentest report, when there are no findings? I did a quick quote tweet with the first thoughts that came to mind:
Which got me thinking, why not write a bit more about this situation? There are multiple resources on writing pentest reports that all highlight different aspects of the general structure and approach of a pentest report, so I won’t get into that, you can find multiple references, including sample reports at the end of this blog post.
Instead I want to only focus on the situation that you have 0, zero, nothing, nil findings. What do you do then?
Understanding the fundamentals
First of all, what did you feel or think when you came up empty handed? Were you dissappointed, did you feel you ran out of time, were you happy? When you are focused on obtaining that sweet sweet pwnage, you kind of forget that the entire goal of doing the pentest is to help the customer improve in such a manner that (repeat) vulnerabilities are minimized and the overal security of the target is improved.
When you realize this, you also realize that when you did find vulnerabilities you immediately thought about “how can this happen?”, “why is this even possible?”, but when you did not find vulnerablities you most probably did not think about “how did they manage to do it securely?”
Those two realizations, in my opinion, are the start to writing a report with no findings. You have to be willing to accept the outcome yourselve first! I think I hear some people object due to “scope”, “time” or other reasons why no findings could be found. Those are contextual limitations, but should not stand in the way of accepting the outcome of your pentest within the limitations that either were imposed or that happened along the way.
The world isn’t straight forward and as consequence communicating the results of a pentest isn’t either. The challenge that you usually have to deal with is, how do you communicate the results of a no findings pentest, without running the risk that it is interpreted as “we are 100% secure”. Which in itself is not so much about the message of not having findings, but much more about:
- Did they have no findings due to contextual limitations?
- Did they have no findings due to their approach?
- Did they have no findings due to ‘being saved by the bell’ every time?
It can of course be a combination of circumstances, but understanding those circumstances and understanding how you finished the pentest with zero findings is an important part of the message that you want to transmit to your client. Let’s look at an example case:
We finished a webpentest (including access to source code) with no findings, mostly because there wasn’t sufficient time to look at all the functionality. In addition, most instances that we thought were vulnerable, turned out not to be exploitable, but just barely, due to a set of circumstances that were just right to prevent exploitation.
In the above example it is not so much about the fact that we have no findings, but about:
- The available time wasn’t sufficient (contextual limitation)
- Their approach is incorrect, although it didn’t result in actual findings
Let’s look at the same example, but then with some slight changes:
We finished a webpentest (with no source code access) with no findings, we had more than sufficient time. The application behaved correctly in all instances, we could not spot any sign of incorrect input or output processing or other kind of logic issues.
The above example is also a pentest with no findings, but let’s look at the why of no findings:
- The application could not be fully analyzed due to lack of source code (contextual limitation)
In the above example we can clearly see that even though we had no findings, there is sufficient room to communicate why we didn’t have findings and how this impacts the interpretation of the report. In both instances the interpretation is different, but this wouldn’t be possible if we don’t understand why we have no findings.
Bottom line: Don’t be afraid to communication that there are no findings, but you need to understand the fundamentals regarding how you got to the no findings part.
Rewarding good behaviour
With the fundamentals out of the way, one of the things that you want to do with a report that doesn’t contain findings is reward good behaviour (actually you should strive to always reward good behaviour). Doing this will enable the customer to learn what they did good and why they need to repeat that behaviour. Good behaviour can be many things, so don’t just think about the technical stuff like “they properly configured the firwall” or “they used prepared statements everywhere”.
When you review your assignment to determine what the good parts of the pentest were, I like to review a mental checklist:
- Was the scope the correct one for the question or risk that customer wanted to cover with the test?
- Do we know why the scope was correct, was this due to something the customer did or something that we proposed?
- Was the customer engaged and helpful during the assignment?
- Was the customer point of contact helpful with providing information which made your test more efficient?
- Were there indications that the lack of findings was due to proper procedures, processes and knowledge at the customer? Also known as being in control of their process
- Did you identify specific technical evidence of approaches/actions/configurations/etc that they should apply more often?
All of the above questions can result in answers that are worth mentioning in your report. The fact that your report contains a positive note, a confirmation that their actions and behaviour are on the right track, will usually ensure that they repeat that behaviour.
Just keep in mind that organizations don’t change overnight, so don’t give up if after your first report where you reward their good behaviour one of the following tests doesn’t turn out as expected. Repetition is very much needed, specially in bigger or less mature organizations.
Contextualizing the information
During the explanation of the fundamentals we learned that understanding the why of no findings is important and we just learned that rewarding good behaviour will help the organization, but hopefully also benefit us as a pentester. However, just by merely mentioning the why and writing down all their good deeds, doesn’t mean we are conveying the message that we want. You still need to actively think about what the message is that you want to transmit. After all communication is a two way street, you can send your data, but you still have to wait and see if it is interpreted as intended.
This means that you have to think about what you want the customer to do with the information that you present to them. So, besides explaining the why of no findings, including the contextual limitations and rewarding their good behaviour for the things that they did correctly you need to answer the question:
What do you want them to do with this information?
Not an easy question to answer, but an important one nonetheless.
Improving future tests
What you also want to mention is how they can better or more efficiently use their budget the next time.
- If the pentest was without source code, should they provide source code the next time?
- If everything was really top notch, should they ‘assume breach’ next time and provide you access to the webserver as a low priv user?
- If everything was top notch and they already did an assume breach test, should they change the frequency of the pentest? If they change the frequency are there other parts of the infrastructure that would be worth looking at?
- Is a pentest really the useful thing to repeat? Would it be more useful to do an architecture review or configuration review the next time?
Specially recommendations on the type of test can be really useful. Some organizations are just not mature enough or aware enough to really understand how they should structure their tests to not only cover the risk of a specific application, but also cover their organizational risk in relation to the threats that they face. Just be very careful of not overdoing it by recommending tests for which the organization is not ready, like recommending an end to end red team test without a proper understanding of their organizational maturity.
oh and don’t forget that making good & specific recommendations for the next test, also makes your own life easier and more efficient. Why perform directory brute forces if you can receive a directory listing? Why perform account brute forces if you can request all their usernames + hashes? Yes, yes, yes I know you test different aspects by skipping different parts of an attack, still I want to tickle your mind to think differently about how you do your pentests. Nobody is immune to the effect of unconsciously doing stuff the same way, because it just works.
Catching the unknowns
So your attempts during the pentest were not succesful, but what if they had been succesful? Would the customer have detected your attacks? Or worse, if you had been succesful and they didn’t detect it could they have performed a forensic analysis of the incident?
This last section of what you could write in a no findings pentest report doesn’t apply to all types of pentesting, but it is still very important. Not having findings doesn’t mean you can’t still be very valuable to the customer.
- What if you included attacks that they should be able to detect?
- What if you included the type of logging required to detect those type of attacks?
Even if you have no detection of forensic skills, trying to figure this out will also help your own learning curve. More importantly, you will trigger the customer to think about detection and response as well instead of only prevention.
You’d be amazed how many organizations are so used to working in silos that part A of the organization doesn’t understand that part B could be of more assistance if they received log files or even knew that certain applications or environments existed. By including detection or logging advice in your report you help the organization to at least get their internal processes poked. No guarantees on the effect, since internal politics can still be very random.
References
- https://pentestreports.com/pentest-report-structure.html
- https://rhinosecuritylabs.com/penetration-testing/four-things-every-penetration-test-report/
- https://www.blackhillsinfosec.com/how-to-not-suck-at-reporting-or-how-to-write-great-pentesting-reports/
- https://www.blackhillsinfosec.com/dos-and-donts-of-pentest-report-writing/
- https://www.sans.org/white-papers/33343/
- https://dradisframework.com/academy/industry/infosec-101/writing-a-security-report.html
DiabloHorn 