Chapter 17
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.
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:
In your final report document, you might want to organize the vulnerabilities as shown in the following list:
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 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.
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:
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.
Table 17-1 Prioritizing Vulnerabilities
|
High Likelihood |
Medium Likelihood |
Low Likelihood |
High Impact |
Sensitive information stored on an unencrypted laptop |
Tape backups taken offsite that are not encrypted and/or password protected |
No administrator password on an internal SQL Server system |
Medium Impact |
Unencrypted e-mails containing sensitive information being sent |
Missing Windows patch on an internal server that can be exploited using Metasploit |
No passwords required on several Windows administrator accounts |
Low Impact |
Outdated virus signatures on a standalone PC dedicated to Internet browsing |
Employees or visitors gaining unauthorized network access |
Weak encryption ciphers being used on a marketing website |
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.
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.
Document the vulnerabilities in a concise, nontechnical manner. Every report should contain the following information:
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.
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.
3.144.222.185