Tip

Essential elements of a good security assessment report

Good communication is important when it comes to improving information security in your organization or for your clients. Outside of security policies and plans, your information security assessment reports will likely be the most critical documents you'll develop in your security career.

@30112 In the overall ethical hacking process, reporting on your results is as important as it is to get permission to do them from the start and to properly plan your testing. A solid security assessment report that outlines what you discovered along with prioritized recommendations on what to do about your findings is essential to make sure things get done and security risks are minimized.

The good thing is that you don't have to be an English scholar or top-notch technical writer to make sure your security assessment reports are effective. In fact, the process of sifting through all your test results is arguably the hardest part of performing information security assessments. Being able to differentiate between the vulnerabilities that are urgent and important and all the others that don't really matter in the context of your business is a critical skill that will come with time and training.

It's all in how you present it

Once you pull your results together and determine which security weaknesses need attention, include the following components. They will help you make up a good technical vulnerability assessment report, which will make your work stand out and increase the chances of something being done about the issues at hand.

Here are the six elements of a good report:

  1. A cover page outlining, at a high level, what was tested (i.e., ABC_Company External Systems), the dates the actual testing was performed, report delivery date, your name, title and other contact information as needed. I also like to put page numbers, the title of the report, and ABC_COMPANY CONFIDENTIAL in the footer on each and every page in the report.

     

  2. A table of contents for quick reference to specific test results.

     

  3. An executive summary to provide a quick glance into what you discovered, the general state of information security vulnerabilities and any trends you've spotted over time. You can leave this section out, but I find that most people like to see it.

     

  4. Notes outlining any security tools used, assumptions, miscellaneous notes and liability disclaimers. I always include the tools I used, which helps add some credibility to the findings and also provides tool information that a lot of people reading the report will like to know. I put in a reminder that the results included are a snapshot in time and subject to change. I also define the categories of vulnerabilities listed such as:
    •  

    • High priority -- These vulnerabilities are directly exploitable and, therefore, need to be addressed immediately.

       

    • Medium priority - These vulnerabilities are not directly exploitable but can be exploited given the right scenario and, therefore, need to be addressed as soon as possible.

       

    • Low priority - These vulnerabilities are not exploitable but may signify gaps in information security standards and, therefore, should be addressed as needed.

    This helps the reader prioritize what needs to be done next.

     

  5. Positive information security findings, such as strong passwords, input validation that's taking place, WPA encryption that's being used and so on to show that there are some good things being done with regards to information security.

     

  6. Prioritized list of findings (i.e., high, medium and low priority as defined above), along with solutions for each. These should be categorized by internal systems and external systems, making it easy to read. Separating each of these sections with a title page helps break up the monotony and allows for quicker reference. Document each vulnerability clearly and concisely. Be as non-technical as possible. It should only take two to three sentences to outline the problem. In addition, I find screenshots to be very beneficial in showing the outcome of a specific test and the system or information that was exploited. For example:


    Using ophcrack to crack the password hashes in the Windows SAM database.


    Using aircrack to crack the WEP key of the wireless network


    Using Metasploit to gain a remote command prompt on a server.

    You may want to include the specific steps that you took to exploit the vulnerability. Also, and perhaps most important, you should provide solutions to the problems you highlight. For example: patching the system to prevent an attacker from using Metasploit to gain a remote command prompt; enforcing strong passwords to keep an attacker from performing brute-force password cracking; and performing input filtering to prevent SQL injection. When you provide solutions to the problems, you give your managers, developers, network administrators or whoever's responsible for fixing the issues clear guidance on where to go from here.

Take your reports seriously

If you're at place where you're formally documenting your vulnerability findings, you're likely taking things seriously and know it's the professional thing to do. First of all, good security assessment reports are good for you: They'll CYA in case something happens in the future to at least show you've been taking security testing seriously. It's also good for your clients' records and your marketing and business development teams when clients and business partners ask to see the latest security assessment report. Finally, it's good for compliance and IT governance because most laws and regulations require ongoing testing and good documentation. Solid security reports are your organization's way to show that ongoing security testing has been taking place when the auditors or regulators ask to see them.

Remember to handle your security assessment reports like the confidential documents they are. If a security assessment report -- or any supporting test data -- were to fall into the wrong hands, it could spell bad news for you and your organization. Think of all the information such a report might contain, like what's hackable and here's how to hack it.

Store the reports and supporting data in a safe place on your server, local hard drive or removable media, and always assume that the worst could happen. This highlights the importance of good physical security (especially for hard copy versions of your reports) and drive encryption to keep prying eyes away. The same goes for when you email your reports. At the very least, zip them with a strong passphrase or create a PGP self-decrypting archive to keep them protected.

About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has more than 19 years of experience in IT and specializes in performing information security assessments revolving around compliance and IT governance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He's also the creator of the Security On Wheels audiobook series. Kevin can be reached at kbeaver@principlelogic.com.

This was first published in December 2006

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.