It’s true that most a lot of people can fall in one of the two categories – business or technical. It is also true that they have to somehow mix and forward their ideas to each other. Without a common ground, it is impossible to create a dialogue about security. When both parties mostly care about different things, the discussions, although long and even interesting, are fruitless. Both the engineers and the management leave the meeting without a plan and a clear vision of what to do next.
Penetration Testing reporting meeting
A Penetration Testing reporting meeting is a point when the technical people have to make business understand the implications of bugs left in the software, the introduced security misconfiguration or negligence in administering the servers. Making the issue critical without a valid explanation or a proof of concept is a known joke. On the other hand, packing the report up with a lot of unnecessary details may be too overwhelming and distract the reader from the problem at hand.
What’s missing?
The problem is, every client is different. Some will want to look at all the details and for some the alert(1) box popping on the site is enough to be scared and take action. There is one part that shouldn’t be omitted though (and very often is!) – a clear explanation of the impact on the client’s asset.
So a tester managed to find an XSS flaw in the web application? Great! But what’s next? Is there any juice to it?
- Is it possible to inject a script?
- It is possible to redirect the user to another site?
- What characters can be used?
A penetration tester doesn’t really have to do a full-blown proof of concept that he can take over the site or drive a country to the ground. Sometimes he has too little time allocated for the engagement to spend a week crafting an XSS payload that will bypass all the filters and steal the password. But he has to know what are the possibilities, he has to know what those filters are and how they work.
Why it is so important?
With a rise of automatic testing tools such as Burp Suite or web scanners (for example Acunetix Website Security Scanner/WebInspect by HP), penetration testers must deliver an additional value to the client. Sometimes it is really easy – an automatic tool won’t escalate privileges from user to admin on your domain controller using some newly-discovered vulnerability. Sometimes it is tricky – why should a client pay more for a web penetration test instead of an automated nikto web scan that is free and apparently delivers the same results?
As always, the devil lies in the details. Explaining the impact in proper, concise and informative way will make the stakeholders understand exactly what kind of risk they are facing. It is important that we provide them with the tools to make a really informed decision on what to do next. It cannot be based on assumptions, overblown statements or straight-up lies. Management has to leave the meeting with knowledge about the vulnerabilities found in their systems, risks that they are introducing and a toolset on how to fix the issues.
Practice what you preach
We’re working hard on a reporting template that will show exactly what I’ve described above – focus on the impact and value to the customer. It’s always going to be a work in progress but you can take a look at the concept here.
For those of you, who want a test sample of the reporting, we are in the process of creating one for you. You can shoot us an email and we will send it out as soon as it’s ready!
Thank you for your interest!