Scoping

Pentesting scope refers to the applications, users, networks, devices, accounts, and other assets which are to be tested to achieve the organisation’s objectives with the pentest.

When defining penetration testing scope, consider:

  • The types of systems to be tested in terms of whether they are on-premise or cloud

  • Existing defenses and security controls, including gaps, vulnerabilities, attack responses, and current security postures

  • System, network, and device configurations

  • System, network, and device tolerance levels during an attack

  • Depth and breadth of attack (sophistication level) in order to compromise systems

  • The entire risk landscape and overall environment in which a threat actor may gain access

Initial meeting example questions

  • What is the purpose of the penetration test? Why do they want one done?

  • Are the systems to test internal systems, external systems, or both?

  • What are the IP ranges of the systems that require testing?

  • What are the domain names of the systems to be tested?

  • Does the organisation own the systems using those IP addresses?

  • Are there any systems hosted by third-party companies such as an ISP or a cloud provider?

  • What applications and services need to be tested?

  • Is testing the physical security controls in scope of the pentest?

  • What types of tests are to be included? Are physical security or social engineering to be included? Are DoS attacks allowed?

  • What user accounts are in scope for password cracking? Are we allowed to attempt to compromise administrative accounts?

With an unknown-environment (black box) test, the pentester is typically responsible for discovering target services, and in some cases even the target IP addresses. If so, we run the risk of performing the test on an unauthorised IP address or system owned by someone else. Even with a black box test we want the customer to give us the target IP addresses and domain names so that we can be sure we have proper authorisations.

Depending on the type of testing being performed, there are more questions we can ask during the scoping of the project. The Penetration Testing Execution Standard (PTES) website has an extensive list of reuseful questions →

Laws, regulations, policies

  • Each engagement is different, and no organisation (and policy) is ever the same.

  • Laws affecting penetration testing varies across countries, regions, states, provinces and even cities.

  • Laws may affect what tools are allowed to be used or exported, or what activities are permitted during a pentest.

Scoping includes considering what laws apply to the target, and what organisational policies affect testing.

Compliance based testing

Compliance-based penetration testing in particular evaluates adherence to organisational policies, laws, and regulations. This type of testing considers the security of specifically defined data types, often within the context of a defined protected environment. Ask about a client’s data classification policies during scoping.

Compliance-based tests may require specific tests to evaluate the secure transmission of data, such as checking cipher strength or performing layer 2 network attacks. These tests may not be applicable in other pentests. We may even be forbidden from directly accessing certain kinds of protected data during testing. In which case, the findings are to only report that access is possible (with proof of course).

In addition to redacting protected data from evidence or providing evidence without directly accessing protected data, we may be asked to link findings to specific parts of a standard or regulation, which may change their “severity level”.

And some governing bodies require that testers be “qualified” before the pentest can be accepted for compliance purposes. UK government entities, for example, require clearance from the National Cyber Security Centre (NCSC) via their CHECK program. Or a CREST certification may be required. Or SANS. Or Comptia+.

GDPR compliance

The GDPR does not define what form testing must take or how frequently it must occur.

A penetration test for GDPR compliance will likely need to evaluate the security of data transfer and data storage and the security of systems that perform transfer, processing, and storage for protected data. Testing will most likely focus on:

  • Identifying what protected data has been collected.

  • Where and how it is stored and transmitted.

  • Access vectors or controls protecting that data in order to help the GDPR-obligated entity to evaluate their compliance according to the terms of the law.

Doing work for an organisation that is subject to GDPR may also require a discussion with our legal counsel in order to confirm whether additional contract language is required during test planning. Do we need to observe any special procedures when accessing, storing, or transmitting protected information during the course of testing?

PCI-DSS compliance

PCI-DSS defines due diligence practices for securing cardholder data and protecting the card data environment (CDE) and provides guidance for penetration tests and organisations that require penetration tests.

Scope includes:

  • Critical systems involved in the processing or protection of cardholder data (public-facing devices and databases) and firewalls, authentication servers or any assets used by privileged users to support and manage the CDE.

  • Application and network-layer tests for any payment application developed by or for the client. If the payment application has been PA-DSS validated, it does not need to be tested.

  • A test to validate that segmentation controls and methods are operational, effective and isolate all out-of-scope systems from systems in the CDE.

  • PCI DSS compliance does not require use of social-engineering, but it is a good way of checking the effectiveness of the existing security awareness program.

This information supplement provides general guidance and guidelines for penetration testing:

GRC compliance

If we are testing in the US, or for an organisation with sites in the US, we may encounter GRC compliance testing. GRC describes the processes, tools, and strategies that organisations use to address compliance with industry regulations, enterprise risk management, and internal governance. Penetration tests are often used to examine risk and comply with legal and regulatory requirements for testing. Such pentests evaluate an organisation’s security regarding the processing and handling of protected data.

Special scoping considerations

There may be other special scoping considerations that may come up during the pre-engagement phase, such as premerger testing and supply chain testing considerations.

Enumerate the in-scope assets

  • What wireless SSIDs are to be targeted?

  • Internet Protocol (IP) range?

  • Internal and external domain names to be targeted?

  • APIs that are to be included? Stand-alone APIs such as custom DLLs? Web APIs such as RESTful web services?

  • Physical locations that are in scope with the penetration test and that we do have permission for to try to bypass physical access controls to gain access to those locations?

  • Domain name system (DNS) addresses used for internal DNS and external DNS?

  • Which and what internal targets (on the LAN) and what external targets (on the Internet) are in scope?

  • Assets that exist on-premises (first-party) and assets that are hosted in the cloud (third-party)?

We must get a separate permission from the third party or cloud provider to perform testing on those assets.