CYA (Consider Your Audience)

Just picking up on one of the points from the discussion Rory Alsop and Chris Riley were having on the penetration testing industry. I've been giving some thought to the issue of communication.

With any presentation or document, probably the most important thing to think about is "who will be receiving this information"? Definitely whenever I'm preparing a presentation, that's the first thing I think about, as it drives the rest of what I create.

Now in the penetration testing industry the main means of communication is the post-test report. Whether that's purely a written document that's handed over at the end of testing, or handled as part of a wash-up meeting, it's the tester's main opportunity to communicate what they did and what the real value of the test was.

Unfortunately in a lot of cases, the opportunity to customize the report heavily for a specific audience isn't available, as it'll go to multiple groups, but with a wash-up meeting there can be some good opportunities to focus on the test in different ways.

To illustrate the point, lets take a pretend test for Hypothetical Corp, which looked at their perimeter network and their main transactional web application.

Lets say there were findings for unencrypted management protocols on external devices, out of date web server software and several web application findings, in session management, authorisation and input validation (SQL Injection and XSS), the standard type of things you may see in many areas.

Now we've been asked to do a wash-up meeting to explain our findings. Depending on who the main people at the meeting are, I'd say there's at least three completely separate ways to present this information.

If we're presenting to developers and admins, you could focus on:

• Exactly which areas of the application had input validation issues, what the best way of mitigating those is, possible ways that their app. framework could be used to help them.
• For the unencrypted management protocols, you might talk about sensible alternatives that still allow the admins to get access (VPN, move to encrypted protocols, partial mitigation like source IP address restrictions etc.)
• Demonstrate authorisation problems in the application and explain how an attacker might be able to get additional access to the system. Again suggesting how you'd recommend that they approach fixing it can be very useful.
  

If we're presenting to the IT Security team you could take a slightly different tack:

• Talking about potential for an attacker to use the issues discovered (eg, SQL injection) to expand their attack and compromise additional areas of the environment.
• Talk about current trends in attacks, providing some information on attacks that are likely.
• Look at what data is potentially compromised by any of the attacks, particularly in terms of any credit card or personal information that may have a regulatory impact if it's lost.

Lastly, you may be "lucky" enough to present your findings to senior management, and again there's probably a different set of things that they're interested in:

• Potential business impacts of one of the findings being exploited. Loss of customer data, regulatory fines etc.
  
• Where the organisation is, in comparison to other companies in their industry or area, is likely to be of interest.
• Demos (if possible). My experience has been that actually demonstrating how easy a compromise is can be quite convincing to senior management.

So here we see three different presentations, all from the same test, and there are numerous other ways that this information could be tailored, depending on the audience.

The main point of all this, is that considering the recipient of any information is key to getting your message across.

Building in time to understand the potential audience at the start of the engagement can be invaluable. For more mature buyers of security testing, agreeing standard formats or documents which have standard sections which can be pulled out as needed can help to get the message across effectively, e.g. a report with a targeted executive summary, plus an xml section for the techies so they can grab the data into their own reporting tool.

One further point which we have seen on occasion is where a test offers findings which are the responsibility of different 3rd parties. Delivering a single report back may not be allowed as confidentiality could be breached. What we have had to do in these situations is write up multiple reports for the same level of audience, but with sections redacted. Planning for this at the start of a test will save you time.