Report writing

- The central deliverable in this entire domain is the pen testing report. A pen testing report is another tool. We've talked a lot about the tools in your toolbox. And this is another tool. It's just as important. And you could even argue it's really more important because this tool is used to communicate your findings and recommendations. Again, you can do a great job in your pen test. But if you don't communicate what you've done and what should be done next, then all of the value is lost, or at least some of the value may be lost. This is the primary deliverable. You've got all these really cool tools that you've been working with and all of these exploits that you've been making sure that you can just follow through and hammer on the systems, but nobody really sees that unless you tell them about it. And this is the deliverable that you can actually communicate what you did. This is many times the only chance that you can make your points. You might get fortunate and sit down with another employee or some of the personnel that worked with the client and you can explain what you're doing during the pen test, but chances are it's during this phase is the only time you get to talk to the decision makers and explain to them how important the work that you've done actually is. So, in short, a penetration testing report is a digest of all of your activities and your conclusions, some of your conclusions you actually drew during the activities and some of them are as a result of post test analysis. So, you're going to be putting a lot of information here and you want to communicate it very clearly and very passionately. You can make a great pen test report look dull and uninteresting. You want to make sure that you make it interesting so that the consumer gets the point and understands how important what you're telling them actually is. So, let's talk a little bit about some best practices. One of the best places to start is to go look at some samples. So, here are a few resources that give you an idea of how to get started and what some other penetration testing reports may look like. The first sample is very simple, and this comes from www.pentest-standard.org. You remember? We've seen this before. This is a great information resource for all things pen testing. But one of the things they do talk about is reporting. In their approach, there's two main areas to the actual report. There's the executive summary, and the technical report. Now, while I agree with that, there's really more detail to it. So, the executive summary, absolutely, very short approach. And then the technical report should actually have many, well, several sections at least. But this is a great way to start. Another example. There is a GitHub public pen testing report repository. If you want to spend some time looking at what other pen testers have done, go through these. You can find examples from pretty much any industry domain you want. And the last two are actual sample reports. So, you have the title page and we had this table of contents. And here we see the executive summary and then we see multiple sections. We had the narrative, the conclusion and appendices. And the last sample, same thing. We've got some header information and here's our contents. Always start with that executive summary and then we have details in the technical report itself. So, these are samples that you can refer to that will kind of get you started. One of the key points to remember is not to wait until the end of the penetration testing activities to start writing a report. There's a lot of stressful activities that go on because chances are you're going to be reaching the end of your activities and there's not a lot of time between the cessation of the activities and actually presenting the report. So, you don't want to sit down after all your tests are done and be looking at a blank piece of paper just to start. So, the key is, start writing very, very early, as early as you possibly can. I like to start writing the bulk of the report at the very beginning of the project. And basically, set the narrative for how you want it to go. And then, as you move through the activities, just add your narrative to the report. Because what you end up at the end is you end up with a huge document with a lot of details, and editing is a lot easier than writing from scratch and it's a lot faster than trying to go from your notes and pop things into this big report. So, start writing early and keep it going as you move ahead. You'll document what you did and you'll capture a lot of knowledge that you may lose or slightly forget if you wait until the end. So, let's cover a few tips for writing that great penetration testing report. Number one tip, tell your story. Remember, what you're doing here is you're not just dumping information on somebody, you're telling a story. There's a whole narrative that you're developing throughout the penetration test report that shows what you did and why it's important and what should be done next. Make sure you know your audiences. When I said audiences, there's different audiences. You have a very high level, maybe C level executive audience that wants to consume that executive summary. It should be one page. Hit the high points, but make your point. But also, know who else will be reading this report. Are they technical? Are they management? Or is it a mixture? And what are their biggest concerns? Are they paranoid they're about to get audited and there's certain pain points that they want to make sure that they don't have to live with? Then you want to focus on whatever the client's pain points and interest level would be. Leave the reader in all cases with a call to action. Don't just dump information. That's not helpful. When the reader finishes reading your pen testing report, they should know what they have to do. It should be basically a to-do list of how to fix these issues. Your report will be your voice after you leave. Maybe you're there harping on what's important. You've got to fix this. This is a horrible problem. You need to change it. But once you leave, nobody hears you. Your report will continue your passion for getting things done properly. So, here's a few questions that you may need to answer in your report. What did you do? Why did you make the choices you made? And what did you find and how did your findings affect your conclusions? So, that's a really good high level outline of the things you want to include in the report. One of the decisions that you need to make early on is a template, or at least a format. A template is great, 'cause then, you just fill in the details, but at least you know what the format of your report's going to look like. Once you do that, you just need data. Now, much of your report will be in a presentation and a summary of that data. So, you'll need to collect data. When you collect this data, this data will be output for many of the tests and activities that you engage in. 'Cause some activities are social engineering, so, there's no test output or log file, but it will be a collection of what you did. You may need to transform the data into a common format. This is often called normalizing data. Because, if you use Nmap, you're going to get output in a certain format. If you use OpenVAS, you'll have output in a different format. Every tool and every activity creates data slightly differently. So, it's important to spend the time normalizing that data. Don't forget this step because normalizing data actually takes probably more time than creating the final report itself. Don't spend too much time on it, but try to harmonize it as much as you can. It's labor intensive if you try to make everything perfect. So, try to use shortcuts and tricks. Use tools like Microsoft Excel. Spreadsheets are great for putting data in a structured format that makes it look more common than just log file listings from different outputs. It's much easier to read and analyze if you pull it all into one big repository. 'Cause that way, you can make reports, you can create charts, do all kinds of things with the data without having to look at tons and tons of log files. So, once you have your data, what does the file or the the report actually look like? We've already looked at some samples and most of the samples you'll see are probably going to be somewhat similar. You need to have an executive summary to start off with. One page maximum. Don't go multiple pages. This will be consumed by high level executive, probably C-level execs and similar to that. They don't have a lot of time to read through these boring reports. Not that your report will ever be boring, but they just want the bullets. Give me the high level summary. That's what it's all about. Target toward your executives. Very few details, just the concepts. You want to state, very clearly state the test goals and the general overall findings. Next, you want to go through your methodology. The methodology is your approach to the overall test activities. And here, you're going to communicate the tools and the techniques that you used, then explain why you did what you did and why you didn't do more. Here is where you set the scope or you explain the scope of your project so that the reader will understand what was in scope and what was out of scope. They won't have to ask questions as to what you did or didn't do. There's also following the basic sections, several common sections that you're probably going to find in every pen test that you write. That would include findings and remediation. This is a ranked list of the findings. It's more detailed than the executive summary. It's basically what you found with the important findings first and what you recommend that the client does. You want to make sure you provide multiple options as it's appropriate. Then you want to communicate the metrics and the measures. And these are details of what you found. So, if we back up for a second, we've got this really short executive summary. Then, we have our methodology which kind of summarizes at greater detail. And then, when we get to metrics and measures, it's even more details of what we found. And how we assessed each finding. Just because we found something, it doesn't mean it's important. So, we want to talk a little bit about how we valued this finding. Why did we put it as number two as opposed to number 12? Just a little description about that. One way to do it is to look at a risk rating or to use a visual risk rating. Let's take a look at an example of risk ratings. This is an example risk rating from www.pentest-standard.org. And it's very visual. You don't even really need the explanation on the right hand side very much. If you just use the green to red, it makes a lot of sense, and most people reading a report are going to understand that the red risks are the worst risks and the green risks are not that big of a deal. So, using something that's visually stimulating will help convey the essence of what you're trying to tell your reader. And then, finally, you'll need a conclusion. The conclusion is a wrap up. It is a summary of everything that you've said, and most important, it is a call to action. Don't forget this part because that call to action gives your report legs and it gives it value. Always keep in mind that the pen test report is a deliverable. It is something that you, as the pen tester, produce and you transfer control and ownership to the client who basically started this whole process. So, there are different responsibilities. So far, we've talked about how you develop this and when you hand it over, you want to make sure that as it hands over and it becomes part of the internal documentation set of the client that you've mapped it conveniently. For example, you have to make sure that you take into account the risk appetite when you create the report. And that is the amount of risk the client is willing to accept. So, this is really a pre-delivery concern. The tone of the entire report is based on the company's appetite for risk. You clearly would write your report differently for a company that was risk averse. In other words, they don't want to take any risk. And that would be different from a company who is very comfortable with accepting risk and really embracing it. So, you want to write your report with the appropriate tone. There should be a risk appetite statement in the report's introduction so that everyone understands how risk averse this tone is going to be. As you transfer control to the client, the client, then, takes control over how the report is handled. The report should be digested, it should be assimilated into the internal organization's document repository. It should be used as input for future pen tests and other types of security assessments. You only have a limited amount of influence at this point, but you want to try to encourage the clients to use this as more than just a point in time report. It should be something that becomes part of a bigger picture. Security policy of the client should state specifically how long reports are kept because they're valuable for more than just a point in time. But at some point, a 20-year-old pen test may not be worth a whole lot. At some point, the value starts to diminish. At that point though, whenever that point is, how is it to be handled. Each client- As a pen tester, you should encourage clients to think about the report handling and disposition. The client security policy should state how assessment reports are stored, how long they're stored, and when they reach the end of the life, what do you actually do with them? Do you just shred 'em and throw 'em away? Are they archived? What happens at that point? Now, we're talking about what happens to your report outside of your domain of control. But you always want to encourage your clients to think about it so that this report has value long after you walk out of the door.