Chapter 10

Understanding How to Finalize a Penetration Test

Once you’ve successfully completed the testing phases of a penetration test, you still have the most important phase to look forward to. Whether you are performing a test for an internal team or you are a contracted penetration tester, providing a quality deliverable is very important. The deliverable for a penetration test is the final report. By providing a quality report, you enable your customer to act on the findings of the report and mitigate the issues found. This chapter starts by discussing post-engagement activities, such as cleanup of any tools or shells left on systems that were part of the test. This chapter also covers report writing best practices, including the common report elements as well as findings and recommendations. Finally, this chapter touches on report handling and proper communication best practices.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 10-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Q&A Sections.”

1. Which of the following items must be cleaned up during post-engagement activities when a web application test includes SQL injection?

1. Shell

2. Active Directory

3. Database

4. File system

2. While performing a penetration test, you are successful in compromising a system you are testing and are able to create your own user on the system. What actions should you take during and after the test to address post-engagement activities? (Select all that apply.)

1. Remove all users created during testing phases

2. Flush all logs of data

3. Record all activities performed on a compromised system

4. Install a rootkit for persistence

3. During the testing phase, you are able to compromise a number of client machines by using Metasploit exploit modules. What types of things might you need to clean up from those systems during post-engagement activities? (Select all that apply.)

1. Shells

2. Files

3. Scripts

4. Master boot record

4. Your company has suffered a data breach. You are now being asked to show proof that you have been doing your due diligence to secure the environment. What can you provide to show this proof?

1. Penetration testing report

2. Antivirus logs

3. Vulnerability scanner report

4. Firewall logs

5. What is the primary deliverable for a contracted penetration tester?

1. Exploitation of the target system

2. Penetration testing report

3. Vulnerability scanning report

4. A list of compromised systems

6. What is the best way to ensure that you do not have false positives listed in your final report?

1. Validate all findings

2. Export the vulnerability report

3. Run an Nmap scan of each device

4. Use only automated scanning tools

7. What is the main concern with cutting and pasting the results directly from an automated vulnerability scan?

1. Format of the text

2. Length of description

3. False positives

4. Copyright issues

8. When should you start to write a penetration testing report?

1. After all testing is completed

2. Before the scope is completed

3. While testing is being performed

4. After all testing is completed

9. A system under test is determined to be running an insecure protocol. What severity level would you give this finding if the device were connected to the Internet?

1. Medium

2. High

3. Low

4. None

10. Which tool included in Kali is most helpful in compiling a quality penetration testing report?

1. Nmap

2. Metasploit

3. Dradis

4. SET

Foundation Topics

Explaining Post-Engagement Activities

Say that you have completed all the testing phases for a penetration test. What you do next is very important to the success of the engagement. Throughout your testing phases, you have likely used many different tools and techniques to gather information, discover vulnerabilities, and perhaps exploit the systems under test. These tools can and most likely will cause residual effects on the systems you have been testing.

Let’s say, for instance, you have completed a web application penetration test and used an automated web vulnerability scanner in your testing process. This type of tool is meant to discover issues such as input validation and SQL injection. To identify these types of flaws, the automated scanner needs to actually input information into the fields it is testing. The input can be fake data or even malicious scripts. As this information is being input, it will likely make its way into the database that is supporting the web application you are testing. When the testing is complete, that information needs to be cleaned from the database. The best option for this is usually to revert or restore the database to a previous state. That is why it is suggested to test against a staging environment when possible. This is just one example of a cleanup task that needs to be performed at the end of a penetration testing engagement.

Another common example of necessary cleanup is the result of any exploitation of client machines. In this example, say that you are looking to gain shell access to a Windows 7 machine that you have found to be vulnerable to the MS17-010 Eternal Blue defect. Of course, when you find that this machine is likely vulnerable, you are excited because you know that Metasploit framework has a module that will allow you to easily exploit the vulnerability and give you a root shell on the system. You run the exploit, but you get an error message that it did not complete, and there may be cleanup necessary. Most of the time, the error message indicates which files you need to clean up. However, it may not, and if it doesn’t, you need to take a look at the specific module code to determine what files you need to clean up. Many tools can leave behind residual files or data that you need to be sure to clean from the target systems after the testing phases of a penetration testing engagement are complete. It is also very important to have the client or system owner validate that your cleanup effort is sufficient. This is not always easy to accomplish, but providing a comprehensive list of activities performed on any systems under test will help with this.

The following are some examples of the items you will want to be sure to clean from systems:

• User accounts created

• Shells spawned on exploited systems

• Database input created by automated tools or manually

• Any tools installed or run from the systems under test

Now that we have discussed the cleanup process of a penetration testing engagement, we will move on to another very important part of the engagement: the report writing phase.

Surveying Report Writing Best Practices

As previously mentioned, a penetration testing report is very important because it is the final deliverable. It is what you are paid to produce as a result of your penetration testing efforts. You should always create a report, even if you are only conducting an internal-only evaluation for your own company. The results of your testing process should be fully documented for several reasons. First, a report provides proof of the work you have completed. Second, it provides evidence of the efforts your company has made to identify any security issues within its environment. This is more important than ever before in today’s world, where executives of compromised companies are being held accountable for data breaches that happen under their supervision. When a breach is exposed, you want to be able to prove that you are doing your due diligence to test and secure your company’s environment.

Now that you understand why it is so important to produce a report from your penetration testing efforts, let’s talk about how to create a good quality report.

Understanding the Importance of a Quality Report

If you are a third-party penetration tester who has been hired to perform a test for a customer, the report is your final deliverable. It is also proof of the work you performed and the findings that came from the effort. It is similar to having a home inspection on a home you want to purchase: The inspector will likely spend hours around the house, checking in the attic, crawl space, and so on. At the end of the day, you will want to have a detailed report on the inspector’s findings so that you can address any issues found. If the inspector were to provide you with an incomplete report or a report containing false findings, you would not feel that you had gotten your money’s worth. You will also run into issues when you try to address the issues with the seller of the house. Most likely, you with both be chasing your tail until you find that the inspector did not provide you with a quality report. Similarly, when you turn over a penetration testing report to a customer, the customer will begin addressing the findings in the report. The customer may begin deploying upgrades or purchasing new equipment based on your recommendations. If the customer finds that one of the reported findings was a false positive, this may cost the customer a lot of money and time, and the customer will likely not hire you back for a follow-on engagement—and that isn’t necessarily a good thing.

Now consider the case of an internal penetration test. Let’s say you are performing an application audit on an internally developed web application. You note in your report that there is an SQL injection flaw in one of the input fields of the application, but you do not validate the finding. Typically, you would turn over this report to management, who would then task the application developer with addressing the issue. Of course, the application developer would want to find a fix for this defect as soon as possible. He or she would likely commit time to researching and mitigating the issue. If after spending time and money on hunting down the cause of this flaw, it is determined to be a false positive, the application developer will come back to you as the tester for answers. If it turns out that you didn’t validate the result, the application developer will not be happy—and you can be sure your management will hear about it. Of course, these are just two scenarios that illustrate the importance of quality report writing. There can be other impacts as well, including compromised systems due to false negatives. However, we will move on to discussing what a quality report is and how to accomplish it.

Discussing Best Practices of Writing a Penetration Testing Report

Penetration testers commonly make mistakes during the reporting phase, most of the time because report writing is the least desirable part of penetration testing. To get it done quickly, testers often take shortcuts, which can lead to leaving out important details. This section discusses a few simple guidelines that will help you produce a quality report.

Knowing Your Audience

One of the most important aspects to keep in mind when writing a report is to know who your audience is. If you write a report that only a highly technical audience can understand and deliver it to an audience that is not very technical, the report will not show its value, and your hard work will go unnoticed. A clearly written executive summary is important because it breaks down the technical findings into summary explanations and provides enough information that all technical levels can understand the results and see value in the deliverable. Of course, you still need to cover all the technical details in other sections of the report. You can see that it is important to consider not only who you are delivering the report to but also who they will be passing it along to. You may end up presenting your final report to the executive or management level. Typically, they will turn over the findings of the report to other teams, such as IT, information security, or development to address the issues found. The technical sections of the report must provide enough information for those teams to be able to take action.

Avoiding Cutting and Pasting

As mentioned earlier, you will use various tools throughout the testing phases of a penetration test, and some of these tools will have the capability to produce an impressive report in various formats. This is a good feature for a tool to have. However, just because a tool has this capability does not mean you should use it to export the findings and simply regurgitate those findings in your final report. There are almost always false positives or false negatives in the results of any tool. For this reason, you must carefully review the results of a tool’s output and try to determine what the actual vulnerabilities mean to the actual target. You must take into consideration the business of the target to be able to determine the impact on the environment. From there you will be able to compile a plan for how the findings should be prioritized and addressed.

Relating the Findings to the Environment

As you compile findings during your testing phases, you will be recording the output of tools that you run, automated vulnerability scanner reports, and general observations. By itself, such data is normally not very useful in understanding the impact or risk to the specific environment being tested. Let’s say you run an automated vulnerability scanner such as Nessus against a Linux server that you found accessible on the internal network. The vulnerability scanner might indicate that it has an FTP server running on port 21. The FTP server software that is running the target host is up to date, and there is no indication from the vulnerability scanner that this is an issue. However, as you continue to discover additional information about the environment you are testing, you determine that this Linux server is actually accessible from the Internet. You then discover, based on conversations with the server owner, that this FTP server was supposed to be decommissioned many years ago. After looking at the logs of the FTP server, you find that employees are still using it to store and transfer sensitive information. This, of course, is a major concern that would not have been uncovered by just reading a vulnerability report. This specific example illustrates why it is so important to analyze the results of your testing and correlate them to the actual environment. It is the only way to really understand the risk, and this understanding should be carefully conveyed in your report. Most reports provide an indication of risk on a scale of high, medium, or low. A quality report provides an accurate rating based on the risk to the actual environment.

Starting the Report While You Are Testing

This is a common question when it comes to data collection and report writing: Exactly when should I start putting together this information? A report is the final outcome of a penetration testing effort. The most accurate and comprehensive way to compile a report is to start collecting and organizing the results while you are still testing. During the testing phase, as you come across findings that needs to be documented, take screenshots of the tools used, the steps, and the output. This will help you piece together exactly the scenario that triggered the finding and illustrate it for the end user. You should include these screenshots as part of the report because including visual proof is the best way for your audience to gain a full picture of and understand the findings. Sometimes it may even be necessary to create a video. In summary, taking screenshots, videos, and lots of notes will help you create a deliverable report. There are some great tools available to help you with this, as discussed in the next section.

Exploring Tools for Collecting and Sharing Information

When it comes to constructing a final penetration testing report, one of the biggest challenges is pulling together all the data and findings collected throughout the testing phases. This is especially true when the penetration test spans a long period of time. Longer test spans often require a lengthier sorting process and use of specialized tools, such as Dradis, to find the information you are looking to include in your report.

Using Dradis for Effective Information Sharing and Reporting

Dradis is a handy little tool that can ingest the results from many of the penetration testing tools you use and help you produce reports in formats such as CSV, HTML, and PDF. It is very flexible because it includes add-ons and also allows you to create your own. If you find yourself in a situation where you need to import from a new tool that is not yet compatible, you can write your own add-on to accomplish this.

Steps in Using the Dradis Framework CE on Kali Linux

Let’s quickly take a look at how you can get up and running with Dradis Framework from a new installation of Kali Linux. This example goes through the process of launching the Dradis Framework for the first time on Kali. It also walks through the initial organization of nodes. Finally, it shows how to import, organize, and analyze data collected from an external tool into Dradis Framework. Follow these steps:

Step 1. Launch the Dradis Framework by using the service dradis start command from a terminal window (see Figure 10-1).

Step 2. When the service is running, open the Firefox browser and access the Dradis web interface by typing in the URL https://127.0.0.1:3000.

Step 3. After Dradis Framework launches, set a shared password for access to the web interface (see Figure 10-2).

After you complete the password setup process, you are taken to the Dradis Community Edition login page, as shown in Figure 10-3. Notice that the Login text box says, “Choose any user name you want.” This is because Dradis Community Edition is set up to use a shared password for authentication. Each user’s activity will be tracked individually, but only one password is used in the shared environment.

Step 4. Log in, and as shown in Figure 10-4, the initial Project Summary screen is pretty empty. From here you will begin to populate the tool by adding nodes. These nodes can be anything that you are collecting information on. For this example, you will create nodes for organizing information collected for a penetration test on a web server.

Step 5. Add a node by clicking the plus sign next to the Nodes section on the left side of the page.

Step 6. When you are prompted with the Add a Top-Level Node popup, label this top-level node Web Server, as shown in Figure 10-5.

Step 7. Because a typical penetration test on a web server includes testing completed on the web applications hosted by the server as well as the operating system that the web server is running on, create two subnodes, labeled Operating System and Web Application. This will be helpful in the testing process because the tester who is completing the web application testing is often not the same one testing the operating system. Figure 10-6 shows the interface for creating a subnode.

As you can see in Figure 10-7, you now have a top-level Web Server node with Operating System and Web Application subnodes. You can think of these subnodes as containers for information specific to those testing tasks.

Now that you have nodes created, you can move on to collecting and importing data. This is where the value of the Dradis tool becomes evident. For this example, you are going to run a Nikto scan against the web application located at http://theartofhacking.org. You will then see how import the Nikto results into Dradis.

Step 8. Collect the Nikto results by running a Nikto scan and exporting the results in XML format, as shown in Figure 10-8.

Step 9. Now that you have your Nikto results exported in a format that Dradis can ingest, go back to the Dradis Framework and import the results by clicking the Upload Output from Tool link at the top of the page, as shown in Figure 10-9.

Step 10. One the Upload Manager page, shown in Figure 10-10, select the Choose a Tool dropdown to tell Dradis what type of output to upload.

Step 11. In the Choose a Tool dropdown, notice the list of available plugins that ship with Dradis CE (see Figure 10-11). If you scroll down to the bottom of this page, you can also see a full list of plugins with the version numbers. For this example, select Dradis::Plugins::Nikto.

Step 12. Select the file to be imported—in this case, niktoscan.xml. As soon as this file is opened, the tool begins processing the file. You can see the progress of the file processing in the Output window, as shown in Figure 10-12.

Now that you have the Nikto output imported into Dradis, you can begin to organize and analyze the collected results. You now see on the left side of the screen, under Nodes, that there is a plugin.output node (see Figure 10-13). This is the default place where the uploaded output will go. You will want to move it from this node into the correct node for storage and later analysis.

Step 13. Click the arrow next to plugin.output to expand the node. Now you can see a node labeled http://theartofhacking.org:80, which is the target that you scanned with Nikto in step 8.

Step 14. Click on the node labeled http://theartofhacking.org:80, and you can see on the right side of the page (see Figure 10-14) an option available for moving the content.

Step 15. Click the Move button, and you see the window shown in Figure 10-15.

Step 16. Because this collected output is related to the web application that you are testing, move the node under the Web Application node by expanding Web Server, selecting Web Application, and finally clicking the Move button at the bottom.

As you can see in Figure 10-16, the plugin output node for http://theartofhacking.org:80/ has been moved under the Web Server/Web Application node.

Step 17. Now that you have your imported data organized in the proper node, take a quick look at the imported results. If you click the node labeled http://theartofhacking.org:80/, you can see the following under Notes: Nikto upload: niktoscan.xml. If you click this file, you see some basic information collected by the Nikto scan, as shown in Figure 10-17.

Step 18. Click the arrow under the Web Application node on the left side of the page to expand the node and see the list of findings from the Nikto scan. Figure 10-18 shows the list of findings under the http://theartofhacking.org:80/ child node.

Step 19. To view a finding imported from the Nikto scan, click on the finding number on the left side of the page, as shown in Figure 10-18. Then simply click Finding under the Notes section of the node properties page. As shown in Figure 10-19, the content of the note is the details of the finding exported from the Nikto scan.

Exploring the Common Report Elements

There are many ways you can go about structuring the elements in a report. Most penetration testing consultants start with a template and customize it based on the type of test and the desired deliverable. Keep in mind that there are published standards that you can reference. This section takes a look at some examples of the elements that should be included in a penetration testing report and discusses the level of detail that should be provided for each of these elements.

PCI Data Security Standard Reporting Guidelines

The Payment Card Industry Data Security Standard (PCI DSS) Penetration Testing Guidance document is a great reference for all aspects of the penetration testing process. It covers topics such as penetration testing components, qualifications of a penetration tester, penetration testing methodologies, and penetration testing reporting guidelines. You can use the reporting guidelines information as a starting point to begin building your own report template. The PCI DSS suggested penetration test report outline is as follows:

Expanding on the Common Report Elements

As you explore the various examples of penetration testing reports, you will see that all the reports are a bit different. Some include elements that others do not. As mentioned earlier, the report content is typically driven by the type of test you are performing and the intended audience that the report will be delivered to. The following sections briefly cover some of the most common elements and what is typically included in them, beginning with the executive summary.

Executive Summary

The executive summary should provide enough information for anyone reading the report to get a clear idea of what the results are. Of course, the executive summary does not include the details of every finding; they are presented in another section. the executive summary must include enough information that a reader can skim through just this section and glean from it the gist of the overall findings.

The following are examples of what should be included in an executive summary:

• Brief summary of findings

• Timeline

• Summary of the test scope

• Who performed the testing

• Testing methodology used

• Summary of metrics and measures, including the number of findings, listed by severity level

• Objectives of the testing effort, including the main topic or purpose of the test and report

• Brief description of the most critical findings

Methodology

The methodology section is where your provide details of the process you followed. Every penetration tester follows a different testing methodology. However, it is best to at least start with a proven methodology and modify as you see fit to form a comfortable method that is suitable to you specifically. In the methodology section of your report, you should provide details of the methodology that you followed and any modifications you made throughout the process. Chapter 1, “Introduction to Ethical Hacking and Penetration Testing,” discusses some available methodologies, including the following:

• Penetration Testing Execution Standard (PTES)

• PCI penetration testing guidance

• Penetration Testing Framework

• NIST Special Publication (SP) 800-115

• Information Systems Security Assessment Framework (ISSAF)

• Open Source Security Testing Methodology Manual (OSSTMM)

• Open Web Application Security Project (OWASP) Testing Project

Finding Metrics and Measurements

When it comes to reporting, it can be difficult to determine a relevant method of calculating metrics and measurements of the findings uncovered in the testing phases. This information is very important in your presentation to management. You must be able to provide data to show the value in your effort. This is why you should always try to use an industry standard method for calculating and documenting the risks of the vulnerabilities listed in your report. On such standard is the Common Vulnerability Scoring System (CVSS), which has been adopted by many tools, vendors, and organizations. Using an industry standard such as CVSS will increase the value of your report to your client.

CVSS, which was developed and is maintained by FIRST.org, provides a method for calculating a score for the seriousness of a threat. The scores are rated from 0 to 10, with 10 being the most severe. CVSS uses three metric groups in determining the scores. The following list gives you an idea of what is included in the metrics groups used to determine the overall CVSS score of a vulnerability:

• Base metric group

  • Exploitability metrics (attack vector, attack complexity, privileges required, user interaction)

  • Impact metrics (confidentiality impact, integrity impact, availability impact)

• Temporal metric group

  • Exploit code maturity

  • Remediation level

  • Report confidence

• Environmental metric group

  • Modified base metrics

  • Confidentiality requirement

  • Integrity requirement

  • Availability requirement

Findings and Recommendations for Remediation

The findings and recommendations section is the meat of a penetration testing report. The information provided here is what will be used to move forward with remediation and mitigation of the issues found in the environment being tested. Whereas earlier sections of the report, such as the executive summary, are purposely not too technical, the findings and recommendations section should provide all the technical details necessary that teams like IT, information security, and development need to use the report to address the issues found in the testing phase. Remember that you must keep in mind your audience. For instance, if you are compiling a report for a web application penetration test, your ultimate audience for this section will likely be the development engineers who are responsible for creating and maintaining the application being tested. You will therefore want to provide a sufficient amount of information for them to be able to re-create the issue and identify exactly where the code changes need to be applied. Let’s say you found during your testing an SQL injection flaw. In the report, you then need to provide the actual HTTP request and response you used to uncover this flaw. You also need to provide proof that this flaw is not a false positive. Ideally, if you are able to exploit the SQL injection flaw, you should to provide a screenshot showing the results of your exploitation. If this is sensitive information from an exploited database, then you should redact the screenshot in a manner that is sufficient to limit the sensitivity. Figures 10-20 through 10-22 provide a sample write-up for a mock penetration test performed on theartofhacking.org. Keep in mind that these are not actual penetration testing findings; they are only examples of how such findings would be written up in a report.

Understanding Report Handling and Communications Best Practices

Say that you have finished a penetration testing report and are ready to hand it over. You may be delivering this report to a client who has hired you to perform the penetration test, or it may be a report of an internal penetration test performed on your organization’s environment. In the case of an internal penetration test, you would likely be delivering the report to the system owners or management. Whatever the scenario might be, you must be sure to follow strict handling procedures.

The contents of a penetration testing report are very sensitive and should be treated as highly confidential. If the engagement involved a Department of Defense–owned system, the contents of the report could fall under International Traffic in Arms Regulations, and mishandling the report could result in millions of dollars in fines and/or imprisonment. As you can imagine, understanding the sensitivity of a report is very important in determining how best to handle reporting and communication. The following sections cover some best practices related to report handling and communications.

Understanding Best Practices in Report Handling

As mentioned earlier in this chapter, report handling is a very important aspect of penetration testing. Many different methods can be followed. In addition, it is important to keep in mind the correct classification of report contents and to control distribution methods and media.

Correctly Classifying Report Contents

The classification of a report’s contents is driven by the organization that the penetration test has been performed on and its policies on classification. In some cases, the contents of a report are considered top secret. However, as a rule of thumb, you should always consider report contents as highly classified and distribute them on a need-to-know basis only. The classification of report contents also determines the method of delivery, which we talk about next.

Controlling Distribution Method and Media

In general, there are two ways to distribute a report: as a hard copy or electronically. Many times, when you perform the readout of the findings from your report, you will be meeting with the stakeholders who requested the penetration test to be performed. This meeting will likely include various people from the organization, including IT, information security, and management. In most cases, they will want to have a hard copy in front of them as you walk through the readout of the findings. This is, of course, possible, but the process should be handled with care.

The following are some examples of how to control the distribution of reports:

• Produce only a limited number of copies.

• Define the distribution list in the scope of work.

• Label each copy with a specific ID or number that is tied to the person it is distributed to.

• Label each copy with the name of the person it is distributed to.

• Keep a log of each hard copy, including who it was distributed to and the date it was distributed. Table 10-2 shows an example of such a log.

• Ensure that each copy is physically and formally delivered to the designated recipient.

• If transferring a report over a network, ensure that the document is encrypted and that the method of transport is also encrypted.

• Ensure that the handling and distribution of an electronic copy of a report are even more restrictive than for a hard copy:

  • Control distribution on a secure server that is owned by the department that initially requested the penetration test.

  • Provide only one copy directly to the client or requesting party.

  • Once the report is delivered to the requesting party, use a documented, secure method of deleting all collected information and any copy of the report from your machine.

Explaining the Importance of Appropriate Communication

The report is the final deliverable for a penetration test. It communicates all the activities performed during the test as well as the ultimate results in the form of findings and recommendations. The report is, however, not the only form of communication that you will have with a client during a penetration testing engagement. During the testing phases of the engagement, certain situations may arise in which you need to have a plan for communication and escalation.

In Chapter 2, “Planning and Scoping a Penetration Testing Assessment,” you learned how to scope a penetration testing engagement properly. You may encounter a scope creep situation if there is poor change management in the penetration testing engagement. In addition, scope creep can also surface through ineffective identification of the technical and nontechnical elements that will be required for the penetration test. Poor communication among stakeholders, including your client and your own team, can also contribute to scope creep.

In Chapter 2, you also learned about the importance of understanding the communication escalation path and communication channels. You should always have good open lines of communication with your client and the stakeholders that hired you. It is important that you have situational awareness to properly communicate any significant findings to your client. You should also know the proper ways to de-escalate any situation you may encounter with a client.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 11, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 10-3 lists these key topics and the page number on which each is found.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

shell

executive summary

methodology

CVSS

need-to-know

Dradis Framework

false positive

false negative

Nikto

PCI DSS Penetration Testing Guide

penetration testing report

Q&A

The answers to these questions appear in Appendix A. For more practice with exam format questions, use the Pearson Test Prep software online.

1. You need to distribute a penetration testing report to a client. What information should you record in your distribution tracking log? (Select all that apply.)

1. Social Security number

2. Date of distribution

3. Unique ID

4. Password

2. You need to deliver soften electronic copy of a penetration testing report to a client. Who should the copy be delivered to?

1. Anyone in IT

2. The administrative assistant

3. The requesting party

4. The manager of information security

3. The CVSS exploitability metrics are part of the __________ metric group.

4. The _________________ section of a penetration testing report should contain the technical details of the findings from your testing.

5. The _____________ section of the report should be written in a way that can be understood by a nontechnical audience.

6. What is the default TCP port the Dradis Framework runs on?

7. You have been hired to complete a penetration test for a large company. The scoping for the engagement has been completed, and you have begun your testing phases. At what point should you start writing the report?

1. Only after the testing is completed

2. When a critical finding has been identified

3. As soon as you start collecting data in testing phases

4. Before the initial scoping meeting

8. During the process of completing a penetration test on your company’s network, you identify a server that is publicly available on the Internet and is vulnerable to a remote unauthenticated exploit. What kind of risk rating would you assign to this finding?

1. Low

2. Med

3. High

4. Critical

9. Knowing your ________ is one of the most important aspects to keep in mind when writing a report.

10. What elements should you be sure to remove from an exploited system before finalizing a penetration test?

1. User accounts created

2. Shells spawned

3. Any files left behind

4. Administrator account