In This Chapter

Bringing your test data together

Categorizing vulnerabilities you discover

Documenting and presenting the results

If you’re wishing for a break after testing, now isn’t the time to rest on your laurels. The reporting phase of your security assessment is one of the most critical pieces. The last thing you want to do is to run your tests, find security problems, and leave it at that. Put your time and effort to good use by thoroughly analyzing and documenting what you find to ensure that security vulnerabilities are eliminated and your information is more secure as a result. Reporting is an essential element of the ongoing vigilance that information security and risk management requires.

Reporting includes sifting through all your findings to determine which vulnerabilities need to be addressed and which ones don’t really matter. Reporting also includes briefing management or your client on the various security issues you find, as well as giving specific recommendations for making improvements. You share the information you’ve gathered and give the other parties guidance on where to go from there. Reporting also shows that the time, effort, and money invested in the security tests were put to good use.

Pulling the Results Together

When you have gobs of test data — from screenshots and manual observations you documented to detailed reports generated by the various vulnerability scanners you used — what do you do with it all? You need to go through your documentation with a fine-toothed comb and highlight all the areas that stand out. Base your decisions on the following:

• Vulnerability rankings from your assessment tools
• Your knowledge as an IT/security professional
• The context of the vulnerability and how it actually impacts the business

So that you can find out more information about the vulnerability, many feature-rich security tools assign each vulnerability a ranking (based on overall risk), explain the vulnerability, give possible solutions, and include relevant links to the following: vendor sites, the Common Vulnerabilities and Exposures website at http://cve.mitre.org, and the National Vulnerabilities Database at https://nvd.nist.gov. For further research, you might also need to reference your vendor’s site, other support sites, and online forums to see whether the vulnerability affects your particular system and situation. Overall business risk is your main focus.

In your final report document, you might want to organize the vulnerabilities as shown in the following list:

• Nontechnical findings
  • Social engineering vulnerabilities
  • Physical security vulnerabilities
  • IT and security operations vulnerabilities
• Technical findings
  • Network infrastructure
  • Operating systems
  • Firewall rulebases
  • Databases
  • Web applications
  • Mobile apps
  • Mobile devices

For further clarity, you can create separate sections in your report for internal and external security vulnerabilities as well as high and moderate priority. One final note: it’s generally a good idea to vet your findings with system owners first to ensure that they’re actually valid.

Prioritizing Vulnerabilities

Prioritizing the security vulnerabilities you find is critical because many issues might not be fixable, and others might not be worth fixing. You might not be able to eliminate some vulnerabilities because of various technical reasons, and you might not be able to afford to eliminate others. Or, simply enough, your business may have a certain level of risk tolerance. Every situation is different. You need to factor whether the benefit is worth the effort and cost. On the other hand, spending a few weeks worth of development time to fix cross-site scripting and SQL injection vulnerabilities could be worth a lot of money, especially if you end up getting dinged by third-parties or lose potential customers. The same goes for mobile devices that everyone swears contain no sensitive information. You need to study each vulnerability carefully, determine the business risk, and weigh whether the issue is worth fixing.

It’s impossible — or at least not worth trying — to fix every vulnerability that you find. Analyze each vulnerability carefully and determine your worst-case scenarios. So you have cross-site request forgery (CSRF) on your printer’s web interface? What’s the business risk? Perhaps FTP is running on numerous internal servers. What’s the business risk? For many security flaws, you’ll likely find the risk is just not there.

I’ve found that with security — like most areas of life — you have to focus on your highest payoff tasks. Otherwise, you’ll drive yourself nuts and probably won’t get very far in meeting your own goals. Here’s a quick method to use when prioritizing your vulnerabilities. You can tweak this method to accommodate your needs. You need to consider two major factors for each of the vulnerabilities you discover:

• Likelihood of exploitation: How likely is it that the specific vulnerability you’re analyzing will be taken advantage of by a hacker, a malicious user, malware, or some other threat?
• Impact if exploited: How detrimental would it be if the vulnerability you’re analyzing were exploited?

Many people often skip these considerations and assume that every vulnerability discovered has to be resolved. Big mistake. Just because a vulnerability is discovered doesn’t mean it applies to your particular situation and environment. If you go in with the mindset that every vulnerability will be addressed regardless of circumstances, you’ll waste a lot of unnecessary time, effort, and money, and you can set up your security assessment program for failure in the long term. However, be careful not to swing too far in the other direction! Many vulnerabilities don’t appear too serious on the surface but could very well get your organization into hot water if they’re exploited. Dig in deep and use some common sense.

Rank each vulnerability, using criteria such as High, Medium, and Low or a 1-through-5 rating (where 1 is the lowest priority and 5 is the highest) for each of the two considerations. Table 17-1 shows a sample table and a representative vulnerability for each category.

The vulnerability prioritization shown in Table 17-1 is based on the qualitative method of assessing security risks. In other words, it’s subjective, based on your knowledge of the systems and vulnerabilities. You can also consider any risk ratings you get from your security tools — just don’t rely solely on them, because a vendor can’t provide ultimate rankings of vulnerabilities.

Creating Reports

You may need to organize your 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. I recommend adding 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.