How to Create Security Testing Reports - dummies

How to Create Security Testing Reports

By Kevin Beaver

You may need to organize your security testing vulnerability information into a formal document for management or for your client. This is not always the case, but it’s often the professional thing to do and shows that you take your work seriously. Ferret out the critical findings and document them so that other parties can understand them.

Graphs and charts are a plus. Screen captures of your findings — especially when it’s difficult to save the data to a file — add a nice touch to your reports and show tangible evidence that the problem exists.

Document the vulnerabilities in a concise, nontechnical manner. Every report should contain the following information:

  • Date(s) the testing was performed

  • Tests that were performed

  • Summary of the vulnerabilities discovered

  • Prioritized list of vulnerabilities that need to be addressed

  • Recommendations and specific steps on how to plug the security holes found

It always adds value if you can perform an operational assessment of IT/security processes. Add a list of general observations around weak business processes, management’s support of IT and security, and so on along with recommendations for addressing each issue. You can look at this as sort of a root cause analysis.

Most people want the final report to include a summary of the findings — not everything. The last thing most people want to do is sift through a 600 page PDF file containing technical jargon that means very little to them. Many consulting firms have been known to charge megabucks for this very type of report. And they get away with it. But that doesn’t make it right.

Administrators and developers need the raw data reports from the security tools. That way, they can reference the data later when they need to see specific HTTP requests/responses, details on missing patches, and so on.

As part of the final report, you might want to document behaviors you observe when carrying out your security tests. For example, are employees completely oblivious or even belligerent when you carry out an obvious social engineering attack? Does the IT or security staff completely miss technical tip-offs, such as the performance of the network degrading during testing or various attacks appearing in system log files?

You can also document other security issues you observe, such as how quickly IT staff or managed service providers respond to your tests or whether they respond at all. Following the root cause analysis approach, any missing, incomplete, or not followed procedures need to be documented.

Guard the final report to keep it secure from people who are not authorized to see it. A security assessment report and the associated data and supporting files in the hands of a competitor, hacker, or malicious insider could spell trouble for the organization. Here are some ways to prevent this from happening:

  • Deliver the report and associated documentation and files only to those who have a business need to know.

  • If sending the final report electronically, encrypt all attachments, such as documentation and test results using an encrypted Zip format, or secure cloud file-sharing service.