Bringing your test data together
Categorizing vulnerabilities you discover
Documenting and presenting the results
If you're looking for a break after testing, now isn't the time to rest on your laurels. The reporting phase of your ethical hacking 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. This is an essential element of the ongoing vigilance that information security and risk management requires.
Ethical hacking 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 ethical hacking 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
Vulnerability rankings from your assessment tools
Your knowledge as a security professional
The context of the vulnerability
Tip
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 reference links to vendor sites, the Common Vulnerabilities and Exposures Web site at http://cve.mitre.org, and the National Vulnerabilities Database at http://nvd.nist.gov. For further research, you might also need to reference other support sites and online forums to see whether the vulnerability affects your particular system and situation. Overall business risk is your main focus.
You can plug in this information to a table in Excel or in Word. I prefer to go through everything in hard-copy form because it's easier for me to read, but your choice might depend on how much data you have. If you think more highly of trees, you might want to just read the results on the computer screen and copy and paste the items that stand out into your final report.
In your final report document, you might want to organize the vulnerabilities as shown in the following list:
Nontechnical issues
Social engineering vulnerabilities
Physical security vulnerabilities
IT operations weaknesses
Other
Workstations and servers
Operating systems
Other
Applications
Publicly accessible
Internal
Database systems
Network infrastructure systems
Hubs and switches
Routers
Firewalls
Intrusion detection systems
Wireless access points
Other
For further clarity, create separate lists for these categories of security vulnerabilities:
Internal vulnerabilities, such as internal hosts and operational issues
External vulnerabilities, such as public hosts, business partner network connections, and telecommuters
The formatting of your report ultimately comes down to your own style and the feedback you get from the other people who read the report. There's no right or wrong here.
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. You need to factor whether the benefit is worth the effort and cost. For instance, if you determine that it will cost $30,000 to encrypt a sales leads database worth $20,000 to the organization, encryption might not make sense. 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. You need to study each vulnerability carefully, determine the business risk, and weigh whether the issue is worth fixing.
Note
Analyze each vulnerability carefully and determine your worst-case scenarios. It's impossible — or at least not worth trying — to fix every vulnerability that you find.
Here's a quick method to use when prioritizing your vulnerabilities that you can tweak 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 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 can set up your ethical hacking 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.
Tip
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 16-1 shows a sample table and a representative vulnerability for each category.
Table 16-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 admin password on a SQL Server system |
Medium Impact | Unencrypted emails being sent | Missing Windows patch on internal server that can be exploited using Metasploit | No passwords required on several Windows administrator accounts |
Low Impact | Outdated virus signatures on a stand-alone PC dedicated to Internet browsing | Cleaning crew personnel gaining unauthorized network access | Weak SSL encryption being exploited on e-commerce site |
The vulnerability prioritization shown in Table 16-1 is based on the qualitative method of assessing security risks. It's subjective, based on your knowledge of the systems and vulnerabilities, but 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. If you need to go more in-depth on your risk analysis, you should check out the OCTAVE methodology developed and published by the CERT Coordination Center's Software Engineering Institute (www.cert.org/octave).
You may need to organize your vulnerability information into a formal document for management or 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.
Tip
Graphs and charts are a plus. Screen captures of your findings — especially when it's difficult to save the data to a file — can add a nice touch to your reports and show tangible exploitations.
Document the vulnerabilities in a concise, nontechnical manner. Every report should contain the following information:
Dates and times the testing was carried out
Tests that were performed
Summary of the vulnerabilities discovered
Prioritized list of vulnerabilities that need to be addressed
If it will add value to management or your client (and it often does), add this information to your report:
Recommendations and specific steps on how to plug the security holes found
List of general recommendations to improve overall security
Note
Most people want the hard copy report to include a summary of the findings — not everything. The last thing most people want to do is sift through a 5-inch-thick stack of papers containing technical jargon that means very little to them.
Tip
Many managers and clients like receiving raw data reports from the security tools on a CD-ROM or an encrypted ZIP file via e-mail. That way, they can reference the data later if they want but aren't mired in hundreds of hard-copy pages of technical gobbledygook.
Your list of action items in your report might include
Enable Windows auditing on all servers.
Put a secure lock on the server-room door.
Harden operating systems based on strong security practices from the National Vulnerabilities Database (
http://crsc.nist.gov), the Center for Internet Security Benchmarks/Scoring Tools (www.cisecurity.org), and Network Security For Dummies.Harden your wireless access point by using the techniques and recommendations presented in Hacking Wireless Networks For Dummies.
Use a cross-cut paper shredder for the destruction of confidential hard-copy information.
Install personal firewall/IPS software on all laptops.
Validate input in all Web applications to eliminate cross-site scripting and SQL injection.
Apply the latest vendor patches to the database server.
As part of the final report, you might want to document employee reactions that you observe when carrying out your ethical hacking 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 manager services providers respond to your tests or whether they respond at all.
Warning
Guard the final report to keep it secure from people who are not authorized to see it. An ethical hacking report and the associated documentation and 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.
When e-mailing the final report, encrypt all attachments, such as documentation and test results, using PGP, encrypted ZIP format, and so on, and then share the password with the recipient via telephone or other secure communication method.
Remove programs and data from the report that a hacker or insider could use in malicious ways, such as tools used (password crackers and network analyzers), log files, and test data.
Leave the actual testing steps that a malicious person could abuse out of the report. Answer any questions on that subject as needed.