Defining objectives with stakeholder questionnaires

This section goes over the various questions that I have used, and That I think are important for this type of engagement. These will help define clear and measurable objectives for the penetration tester.

Let's have a look at a questionnaire to determine the engagement criteria:

• What is the objective of this penetration test?
• What will be the deliverables required at the end of the penetration test?
• What is the length of the penetration test, and is there any period of time when the penetration test cannot happen? (For example, the customer may have a busy period during the day when they don't want anything to interrupt their business processes)
• During the penetration test, does the penetration test stop at finding vulnerabilities, or does it proceed to actively try to exploit these vulnerabilities? (This question is important because the stakeholder may not want systems to be taken down or potential data modified/deleted, so we want to make sure we know the boundaries) If exploiting systems is acceptable, do you want the penetration tester to try lateral movement within the environment after that?
• Will this be an internal penetration test, an external penetration test, or both?
• Who are the contacts within the company?
• Are there any compliance standards that the company needs to follow?

Scoping criteria

We will now see an example questionnaire for the scoping criteria. First, we will start with questions that will be derived from a white-box tester only to gain intimate knowledge of the network for testing:

• What are the subnets and/or IP addresses in the scope of this test?
• Are there any systems that are out of scope?
• Are there security devices within the network? (This is important because these devices may block access into an environment, and that will prevent testing the system correctly)
• Is there any type of important data held or transferred within the environment?

Finally, if the penetration tester is using more of a black-box mentality, then these questions will be relevant for them, as well as the white-box testers:

• Is guest access in scope as well?
• Which corporate SSIDs are in scope?
• What are the physical locations in scope for the test (if there are multiple locations)? Are all locations/networks dedicated, or are they shared with another company (for example, shared hosting or some cloud environments)?

This list is by no means complete or comprehensive. It is important for you, as a penetration tester, to figure out what questions you feel are relevant for your particular engagement. The preceding list contains some of the required questions, based on my experience.

Documentation

Documentation is an important part of the planning and preparation phase. Sometimes, this information is not provided to you, and you must glean it yourself. In Chapter 2, Information Gathering, we will focus on getting some of this information as well, if it is not all provided.

But hopefully, you can get some information about the environment prior to jumping into the penetration test. There are different types of documentation that are great to have prior to starting a penetration test. In the next couple of sections, we will see some of the main types of documentation that we need during the preparation phase.

Documentation is great, but part of a penetration tester's job is also to verify that it's correct. We have seen way too often documentation that was outdated and/or incorrect. Use it as a guide for the test, but by no means should you use it as the single source of truth.

Understanding the network diagram – onshore IT example

A network diagram of the systems and devices that are in scope is important to get a good understanding of the network so you can start working on your overall penetration plan. This documentation will allow you to see what systems are in scope, as well as the path through the network and devices that are involved. A lot of organizations struggle with this type of documentation, so use it strictly as a guide. One of the deliverables might end up being a more comprehensive network diagram for you, based on what is discovered during the penetration test.

Network diagrams come in all shapes and sizes. The important thing is to have it for the in-scope networks and to show the main network devices, security devices, and hosts, if at all possible. The following is a sample network diagram that I created. This will give you a good idea of what to look for:

 

Data flow diagram

Data flow diagrams are probably one of the most important documents a penetration tester/assessor/auditor can have. The job of a data flow diagram is to show the flow of important data within the organization. The data can be of different types, including credit card information, proprietary company information, or even personally identifiable information (PII). Understanding how this type of data flows in the network, and which systems it interacts with, will allow you to help the penetration tester understand where to focus. This is important as this is where the hackers will focus as well.

Some organizations do not typically have this type of documentation. We have seen many companies having to generate these data flow diagrams while going through an audit or assessment of some sort. But most organizations should have data flow diagrams within the organization for any important data flows.

A great outcome of the penetration test is that this type of documentation may end up being verified by the penetration tests to show its accuracy. Documentation is often a low priority at most companies, unfortunately, so being able to keep it up to date is important.

Here is an example of a data flow diagram of a sample company we created, showing credit card information flowing throughout the network:

Organization chart

You may be wonder why an organization chart is a valuable and required piece of documentation for a penetration test. But when you think about it, people in higher positions tend to get targeted because they have the power to transfer money, or have access to important items. Knowing the chain of command for all employees within an organization allows us, as penetration testers, to see other individuals that can be targeted with the hopes of getting all the way to the top. This information can help show the penetration tester whom to potentially target first. It may be easier for a hacker to get a junior accountant to click on a link and install the malware for the hacker to have remote access than it would be for them to try the same approach with the CFO. Now, we are pretty sure the CFO will have more access compared to the junior accountant, but once you have a foothold within an organization, moving around becomes a lot easier. Remember: People are typically the weakest link in security.

Here is a simple example of an organization chart: