Chapter 9
Preparing for the Pen Test
IN THIS CHAPTER
Taking care of upfront tasks
Determining the requirements of a test
Choosing a scan type and the appropriate tools
Knowing when and how to not go through with it
Becoming familiar with types of attacks and a pen tester’s tools are necessary early steps to using those tools to protect a company’s assets against hackers and their nefarious intentions. Before you dive into the testing, assessing, and preventing, however, there are certain preparatory tasks to take care of.
In addition to knowing what attack type you’re exploring and what tools you need to use to do that, you must understand your role, which systems you’re testing (or not), and what the stakeholder’s goals and expectations are. I cover all of that in this chapter and more, including what to do if you have to end a test before it even gets started.
Handling the Preliminary Logistics
Before you get to the part where you will do any pen testing, you must work out certain logistical details, including getting permission to do the tests. This section highlights and explains those logistics.
Holding an initial meeting
You’ll want to have a meeting to discuss roles, responsibilities, and expectations. This brings together all involved parties, who are assisting with the scan, mitigating any risks that may be found, or simply providing the necessary permission to have the work done.
In this section, I focus on what will happen in the initial meeting with the stakeholders — roles established, expectations discussed, the scope defined. Note that a series of meetings will be necessary, however, as you begin other preparations, which involves gathering requirements. The stakeholders might decide to set up a weekly meeting, or have them even twice a week, for the life of the project.
Understanding everyone’s role
You must understand what role you’re playing in the scenario in front of you. For example, if you’re working for a large company as part of their in-house security team, conducting a pen test will be slightly different than if you’re hired as an outside consultant who will assess and pen test for the client. You’ll do everything the same, but the role you play may be slightly different.
Note that, as a pen tester, your role is first and foremost to conduct penetration tests to find weaknesses in an organization’s security plan. You might or might not be expected to make recommendations on your findings and then implement those recommendations to secure the identified weaknesses. That all might be someone else’s responsibility, too, making it so important to hash out these issues ahead of time.
As a pen tester (especially one who is a consultant), you may want to suggest a clear identification of roles and responsibilities. Figure 9-1 shows a generic RACI (Responsible, Accountable, Consulted, and Informed) chart that you can customize however you see fit. This chart is used to list who is part of the project, who’s responsible for what, who’s accountable for specific tasks, and so on.
This chart is a good way to verify the scope and set boundaries, as well as document the set of deliverables and who will perform them and keep concerned parties involved to the necessary level (consulted, informed).
Setting expectations
If the expectation is that you will conduct a pen test to test the security of the enterprise, you have been given a very wide and non-specific task to follow. You may need to cast a wide net to get a good catch.
FIGURE 9-1: Use a RACI chart to identify roles and responsibilities.
On the other hand, you might be given a very specific task such as ensuring the company’s trade secrets are safe from prying eyes — internally and externally. You now have a more specific goal to accomplish.
Setting scope
Clarifying what exactly your task will be is determining the scope of your work. Whoever is asking for your services should detail the scope up front. The scope discussion should absolutely be part of your meetings with stakeholders because they’re setting the expectations and goals. Topics to discuss include
- Whether this is an in-house pen test or a consultant pen test.
- Whether this is a one-off task or part of a program.
- If part of a program, how retesting will be handled.
What will also partially dictate scope are what you see in past test results and the existing risk register, if there is one. I discuss both in the later section, “Gathering Requirements.”
Gaining permission
Being a great pen tester requires you to make great assessments about the pen testing you’re conducting. You are an ethical hacker conducting an active penetration on an enterprise network with permission. This means you will have to ask for permission, and that might require going through a formal process.
Gaining permission to conduct a pen test is a multifaceted process. Many aspects fall under the umbrella of what you should discuss early on:
- It depends on the size of the company and those who are tasking you to accomplish it. Who ultimately gives permission might not be anyone you’re dealing with directly but who’s higher up the chain of command.
There also needs to be specific guidelines on next steps and what you have the access and rights to do.
For example, you may find a weakness outside the boundaries you were given and think it’s a threat. The right thing to do is to escalate it to those who need to know immediately and seek further guidance, not probe and try to exploit it.
- Gaining permission should be part of the first series of meetings that take place once the roles have been assigned and the tasks have been agreed upon and approved.
- You may want to have a test done in covert fashion to really test those who might be involved in securing systems. You may need to obtain separate permission to do this.
- You may also corrupt data (so you need a backup), or you may cause another problem that needs to be addressed. These are also issues to address during the permission discussion.
- You will have a strategy for how you’ll approach and conduct the pen test. Share this strategy with the stakeholders, so they understand your method and everyone knows what you’re doing, and they can confidently provide you the permission to do your job.
Following change control
You will likely need to do a change control to document the fact that a change (scanning, testing, and attempting of changes on your network and systems) will be taking place.
Change control is necessary to document what is happening but also to log the time, date, and other useful information needed if an incident arises from the scan itself and support teams need to mobilize to assist. A critical prep item should be a contingency plan if something goes wrong. See “Having a Backout Plan,” later in this chapter, for more about contingency plans.
In my experience, I have seen older systems and interfaces fail due to excessive scanning that caused a technical failure to occur. I have also seen triggers, thresholds, and alerts set that starts to shut down things when an attack may be present and cause a production outage. Also, your operations teams (who may not be on the RACI or know about the scans) may start to see suspicious activity and think they are under attack and start to respond to a false positive.
All these scenarios and more can be solved with a change ticket and/or change control. In the cases where you may not be able to follow this process (smaller companies might not have a process), you may want to consider an alternative so that you can track the work being done and avoid issues.
Keeping backups
Make sure you not only have backup of data, but backup of systems, software, firmware, access to all of this, and so on. If virtual, snapshots of data/systems VMs hosts and other pertinent data suffice.
Having documentation
Larger companies might automatically have everything in writing. If not, ask to have documentation in place that authorizes your scan (and all your activities) and any steps needed to restore data, recover from disaster, and so on.
Gathering Requirements
Gathering requirements is based on the scope of what needs to be done, but at the same time, the requirements you gather might indicate what needs to be done — and that could be different from what you or stakeholders expected. For example, the scenarios provided in this chapter can still serve to show you differences in the requirement gathering process. If I am going to do a wide assessment versus a deep and specific assessment, the requirements for each might be different. In this example, the wide assessment may require a set of tools and specific access to the network both internally and externally. In another scenario, you may only need to scan internally and start your pen test from a wireless access point.
This is why it is crucial to assess past results and the risk register — it helps you define the scope. You need that to refine the actual tools, strategy, vectors, and strategies to accomplish a good pen test. As you refine your strategy, you will provide status updates at the regular stakeholder meetings I discuss earlier in this chapter. Keeping everyone apprised will ensure no one (including you) gets a nasty surprise.
Reviewing past test results
The next part of assessment and prep work is in looking at what has already been done before you start to conduct your pen test. The reason you do this is because the more you know, the better equipped you’ll be. This is especially important if you’re conducting a pen test for a company for the first time. Find out what you can from previous assessments (and check the risk register, which I cover next) to discover if you need to do an immediate retest and see if you still have open vulnerabilities based on previous assessments.
If you’ve done pen tests for this company before, you may have (and I really hope you do!) saved reports or logs in assessment tools already available to review as shown in Figure 9-2. Part of testing is to make sure you’re documenting the experience so that you can either mitigate the risks or document them and monitor them if you can’t repair them. Having that documentation for future reference is invaluable.
If and when possible, discuss with other IT security team members who have conducted previous assessments. Ask them for any artifacts from past results and scans that they can share. Remember, use the RACI chart, so you know who you are authorized to talk to and what you are allowed to divulge.
Consulting the risk register
The risk register is where all the vulnerabilities you find and need to mitigate wind up. If previous pen tests have already been conducted, there should already be a risk register with entries you can review. Figure 9-3 shows risk register metrics you can consult to determine whether there are areas in which you may want to tailor your current scans, tests, and assessments.
FIGURE 9-2: Consult past results to help with future tests.
FIGURE 9-3: Reviewing threats on the risk register.
For example, you may find that a large number of vulnerabilities in a Release Management category. You may find that as updates are sent to the enterprise, it causes more problems than can be fixed, solved, or mitigated. In this case, you might decide to run pen tests that test the integrity of your desktop systems, applications, and other programs to make sure no known vulnerabilities still exist (or new ones have cropped up) in this focus area.
Coming Up with a Plan
After you have consulted prior test results and the risk register, you’re getting closer to being ready to conduct a pen test. What you’ve assessed so far in this chapter, as an example, has shown the need to do a wide scan first and then drill down to specific areas that may present threats. Recovering any data of value in an APT type format is desired as an expected outcome.
Figure 9-4 shows the attack vector. Broken into steps, it looks like this:
- An internal user comes in via wireless.
- The user attempts to find access to a database with valuable information and remain undetected.
- The user continues to access data until exfiltrating undetected with the company data.
With this information in hand, you can select tools you believe may be helpful in getting this pen test accomplished, deciding the best vectors to take, and determining how you could go about doing this exact test in Chapter 10.
FIGURE 9-4: Reviewing attack vectors to devise a test plan.
Selecting a project or scan type
When preparing for a pen test, one of the first things you need to pre-plan is the tool selection because once you know what tools you need, you know what options are available within the tools.
This may seem like common sense and it is; however, there are many variables based on the scan type, what the stakeholders are asking for, if you’re just running a quarterly, monthly, or annual scan or possibly just running a test of your tools for accuracy or practice. Because of these variables, consider what tool you need to use and then what vectors you are accessing. For example, you need different tools to access a wired network versus a wireless network.
Next to consider are the types of scans you may do to gain information. Because you need to be connected to a wireless network to conduct the test, consider wireless enabled tools such as Wireshark and its wireless functions. Other scan types you may want to consider revolve around network mapping (Nmap) and a basic network scan with Nessus (see Figure 9-5) and others to gain the info you need to conduct an APT.
FIGURE 9-5: Reviewing Nessus scan templates.
Selecting the tool(s)
In this section you select your tools. In general, you use the most common of tools (including Nessus, Nmap, Kali, Wireshark) and other system and operating system tools to help you conduct an APT.
Before getting started with the pen test, you also need to get your toolkits ready for the task. For example, if you know that you may want to see whether you can access FTP servers, you can tailor a set of FTP filters that can pull the specific info needed immediately. Based on what data you’re able to gather, you may need to search for usernames and passwords sent that can be used in your APT. Figure 9-6 shows Wireshark’s filter option that can be used quickly to get to the data you need.
FIGURE 9-6: Tuning tools with filters for prep.
Having a Backout Plan
Before you begin, you should already know how you will terminate when you need to. If a pen test is causing an impact, you should consider dealing with the impact and stopping the pen test. If you have an impact based on a tool being run, stop the tool or pause it so you don’t lose your place.
For example, some scan tools are pausable so you can start the scan again from where you left off and not duplicate your efforts. Regardless, you’re one of the good guys so if you’re seeing an impact (or an impact is brought to your attention), shut down your test and reassess where you are and what is happening so you can resume later. If you break something, get it fixed. If you corrupt data, get it restored and move forward from there.
To set up a backout plan consider the following:
- What tool you’re using and how to stop it from its intended actions.
If a tool is set in motion and starts to make changes, know what those changes are and how to fix what the tool may have damaged.
These points should all be documented in the change control document. Also, actively monitor the pen test so that you can identify when things go awry and be able to react to them immediately. If you’re monitoring the tool and recording the outcomes in documentation for your after-action review of the scan, you can more likely identify when an issue takes place and be able to react to it immediately.
- Ensure that any system you intend to scan has been identified as a system that has been backed up and or is resilient with some form of virtual backup or clone of the system. This way, if an issue takes place, the system or the system data can be restored immediately.
As you conduct your pen test, if you find a major incident issue, you need to bring it to your leadership and stakeholder’s attention immediately. Examples of this would be threats that if conducted could take down the entire environment and cause immediate loss to life, critical data, and or the operation itself.