Report Writing 101: Finalizing a Report
Tickets, please
Hello all. We are once again exploring the world of report writing. This might seem boring to you (don’t worry, it’s boring to me), but being able to write and craft what you’ve done (and what you can do) into readable language is a very valuable skill that is required in the work world. Just to reiterate, being able to write a report extends into other forms of writing as well. This ranges from letters of recommendation to project proposals, even asking for pay raises. It’s something you should know how to do well, especially if you’re still looking for a job.
Before You Read
It is recommended to read these related posts before reading this one, so that you don’t get lost during the discussion of the concepts:
What
So at this point, we have done the assessment, we have our notes that we wrote during it, and we need to finalize it all into a report (and write tickets!).
In a nutshell a report will look something along the lines of this:
Title
Subtitle - Summary
A title plus summary of the tool/product and a brief overview of the structure of how the assessment was done. Depending on the format of the assessment, you could also list engineers that also worked on the assessment alongside the product stakeholders (the blue team).
Subtitle - Findings
Within the findings tab will be what you found. Of course, what is to be listed here will fall under the scope of the assessment. If kernel tools (like writing a driver that gives you the permissions to read inaccessible memory) are out of scope, you probably shouldn’t put them here. Who writes a driver to give themselves permanent access to Microsoft Office?
At work we adopt a severity/likelihood ranking, where we list the severity of the issue that was found and the likelihood of it being exploited in the wild. Alongside these are also notes or comments about techniques used/deployed and the link to the corresponding ticket #.
It is also advised to separate the issues you’ve found into subgroups. This is especially helpful with assessments that have a lot of findings. For example, using the “Freaky Foresters” product from the Scope post, we can separate the findings into sections for client-side resilience, server-side resilience, network integrity, and product integrity, given that issues were found for each.
Subtitle - Closing Remarks/Next Steps
Once all of the terrible things you’ve found are listed, you can then provide an “educated guess” as to how the product will fare once released. If its a product from a popular company/studio and will have high traffic, you can expect the likelihood of cracks/exploits to be high, and can adjust your wording as such. Your close remark is mostly just a summation of your findings plus the likelihood of exploits being written for the product. After this, you can also provide a “next steps” paragraph describing a path that the blue team can take to improve their product. This is also where you shill the products that your company provides (e.g. anti-tamper software) to further secure the blue team’s product.
Ticket Time
Tickets are a bit of a pain, mainly because you have to repeat yourself 1000 times. In most cases, you’ll just go through each of your findings and write up a ticket.
Within a ticket will more or less be a copy and paste from the main report, but you’ll want to add a few extra things.
Reproduction steps
This is where you list the technique(s) you performed to recreate the exploit/issue. Usually this is just “step 1: hook this function. step 2: change the parameter to something else” because most issues (at least that I’ve found) are just desynchronizations between server and client. Nothing too special here, just simple steps of recreation.Methods to resolve
This is where you tell the blue what they should do. For example, if there is an issue where the client has an infinite amount of lightbulbs that he or she can access at a time, then you would list something among the lines of “perform server-side validations for the amount of lightbulbs allotted for a client”. You can (and should) be broad. It isn’t (shouldn’t be) your responsibility to create a an entire solution for the blue team. Make them earn that paycheck.Extra comments
This is just for more detail about the issue. You don’t want your main report to be super wordy, as most of the time the blue team just wants to know “what’s wrong” and “where is it”.
Don’t forget that some ticket software allows a cloning feature. Very nice.
Now that your report is done and the ticket writing is done. All that’s left is to send “the email” and show the blue team what awful programmers they are.
That’s all for this post. Hope you got something out of it. Have a great weekend.
Go!
-BowTiedCrawfish