Penetration Testing - Scoping an Engagement

As part of planning an engagement, scoping needs to be taken into consideration. Scoping ensures that a mutual understanding is made between the penetration test team and the organization requesting the penetration test (the client).

Scoping an engagement consists of:

• Defining the scope
• Creating a target list
• Identifying restrictions
• Defining the rules of engagement
• Defining the assessment type
• Validating the scope
• Defining limitations and permissions

Defining the scope

Proper scoping ensures a cost-effective penetration test. Everybody involved with the engagement should have a clear understanding of the penetration test’s goals and objectives. Defining an engagement scope has become more complicated over time given the rise of wireless location area networks, VPN connections, and the adoption of cloud infrastructure. With this said, one of the first things that should be conducted when defining a test scope is to understand the architecture of the client’s network. Is the entire network on premise? Or has the organization set up their network infrastructure completely in the cloud? Perhaps the network follows a hybrid model. Beginning to ask these questions can help to start to define the lines that can be followed by the penetration testers.

Identifying web or mobile applications should also be under consideration when defining the engagement scope, given the fact that different tools will need to be used when testing for vulnerabilities in desktop vs iOS and Android.

Lastly, it will be important to also define the scope of permissions that testers will be granted before testing. Should testers operate under the guise of an unprivileged, privileged, or root user? Perhaps the client will request to have testers operate under multiple types of users. All of these considerations need to be made before beginning the engagement.

Creating a target list

Creating a target list helps to define the scope of an engagement by understanding how penetration testers will operate. Testers should understand whether they will need to operate as an internal or external threat, as well as understand if 1st party hosted servers or 3rd party hosted servers can be targeted. In addition to engaging against a network, a penetration test may also target the client’s physical infrastructure. Something else to consider when defining a target list, particularly for clients that have multiple locations, is defining the network list. Perhaps the client will only want their North American locations to be targeted and for their South American locations to be exluded from an engagement.

When creating a target list, the question comes up of whether the engagement should be a black box, grey box, or white box engagement. For instance, receiving a list from the client of all of the domains and sub-domains that should be tested on the client’s network but does not give testers access to proprietary code would be an example of a grey box engagement. A black box engagement would not disclose any of this information, while a white box engagement would disclose all of this aforementioned information.

Identifying restrictions

Understanding the client’s risk tolerance will also be an important pre-requisite before beginning an engagement. Risk can be avoided, transferred, mitigated, and accepted, and understanding the client’s perspective on risk will help testers understand what restrictions should be put in place before beginning the engagement. Communicating to the client what operational impact that an engagement can have will also help set boundaries for testers to know in which environment the test should be conducted in and how aggressive testers can be in the engagement.

The schedule and timing of the engagement should also be well defined. Some clients will be more precise about when an engagement window can occur, while other clients may have more latitude. The window of engagement should be negotiated as part of defining the scope of the engagement.

Defining the rules of engagement

The rules of engagement, or ROE, are ground rules that both the organization and the penetration tester must abide by.

The ROE for an engagement should consist of:

• Timeline - represents a series of events that transpire within a discrete period
• Locations - a set of authorized locations should be listed, especially those that cross international borders
• Time restrictions - specifies when testers are authorized or unauthorized to conduct exploits and attacks
• Transparency - a trusted agent should be designated as a monitor in the organization during the assessment, ideally an in-house staff member
• Boundaries - refers to what systems may be targeted or what techniques can be utilized

Types of assessments

There are many different types of penetration engagements that can be performed:

• Goals-based - an assessment with a specific goal in mind, such as finding out as many ways as possible that a location can be broken into
• Objectives-based - an assessment where the tester seeks to ensure that information remains secure, these tend to be more like a real attack
• Compliance-based - an assessment that focuses on finding out if policies and regulations are being properly followed (but bear in mind compliance does not equal security)
• Pre-merger - an assessment that is conducted before two companies merge with each other in a period of time known as due diligence
• Supply chain - an assessment that occurs when a company requires its suppliers to ensure that they meet a given level of cybersecurity requirements
• Red team assessments - an assessment against the organizational network that is executed by their own internal penetration testers

Validating the scope

After the rules of engagement have been defined and the assessment type has been finalized, the scope of the engagement should be validated through:

1. The scope and the in-scope target assets
2. What is excluded from the scope and considered out of bounds
3. What strategy will be used
4. What the timeline will be for any testing
5. Any restrictions or applicable laws that will apply to the engagement
6. Any third-party service providers, services, or off-site locations that are being considered
7. The proper communication channels to use during the assessment to provide updates to key stakeholders

The allowed list and excluded list of authorized and unauthorized targets should be defined as well as possible security exceptions that may need to be utilized as contingencies.

Defining limitations and permissions

Throughout the course of the engagement, testers may encounter or be exposed to confidential information. If or when this occurs, it is important to make the organization aware of this as an unauthorized disclosure, even if by accident, may make your team liable for any damages that occur.

It will be the responsibility of the penetration testing team to comply with all written contracts that have been supplied before the engagement began, this includes:

• the statement of work (SOW)
• the master service agreement (MSA)
• the service-level agreement (SLA)
• the non-disclosure agreement (NDA)

Remember that under the terms of these documents, both the invasiveness of the engagement and the tools that may be used may need to be limited under the definition of the engagement’s scope.

A good rule of thumb in penetration testing is that it is better to ask permission than to beg forgiveness.

Scope creep

The final item that should be considered as part of scoping an engagement is understanding and identifying scope creep. Limiting scope creep up front will help save pressure and stress on testers while also clearly defining boundaries for the client. If something in the engagement needs to change or be added throughout the duration of an engagement, then an addendum should be applied to the engagement in order to be correctly tracked and understood between the client and the test team.

• Source: Dion Training - Udemy
• Image courtesy of: Outpost24