Scoping

Scoping in a penetration testing (pentest) engagement refers to defining the boundaries, objectives, and limitations of the assessment. It involves determining what systems, networks, applications, and assets are included in the assessment, as well as identifying the goals and objectives of the pentest.

Important Points to Look at

Why the client is asking for an assessment?

-> Compliance (PCI, ISO)

-> Test Maturity of their Security Program

-> Look for weakness in the Architecture

Assessment Timing

-> How long will the testing last?

-> Does it need to be done during certain hours?

-> Will it interfere with any special projects?

Internal Involvements

-> Who is the primary point of contact (for Security and the Product)

-> Communication for the engagement

-> Will the IT/Responsible party be notified of the testing?

External & Internal VA/PT

• Clearly define the targets (hosts, IPs, applications) for the penetration test to focus testing efforts effectively.

• Document and communicate exclusions to avoid unintentional testing of restricted areas.

• Determine if notification to third-party providers is required when testing external systems like SaaS/PaaS solutions.

• Understand the process for accessing internal systems within the network environment.

• Identify the presence of IPS/IDS/Firewall and understand their impact on the penetration test, including how they handle blocked traffic.

Template

The following is an example of a template for scoping a Pentest.

Objectives

Identify and exploit security vulnerabilities in the e-commerce platform to assess its resilience against cyber attacks.

Inclusions

• Application Front-End/Mobile Application/API

• Back-End Server Infrastructure

• Database servers storing customer information

• Payment processing systems

• Web application firewall (WAF)

Exclusions

• Third-party services not directly managed by Company X (e.g., external payment gateways)

• Physical security assessments of Company X's office premises

Rules of Engagement

• Testing will be conducted during off-peak hours to minimize disruption to customers.

• Testing methods will include automated vulnerability scanning, manual penetration testing, and social engineering.

• Testing activities will not intentionally cause service downtime or data loss.

• All findings will be reported promptly to Company X's security team.

Access Requirements

• External testing: No special access requirements; testing will be performed from external IP addresses.

• Internal testing: VPN access will be provided for internal network testing.

Risk Considerations

• Potential impact on customer data confidentiality, integrity, and availability.

• Compliance with industry regulations (e.g., PCI DSS) governing e-commerce security.

Decision Making Skeleton 💀

Below is a basic decision-making framework that can be used to finalize the scope of a pentest engagement in advance. This framework helps improve the decision-making process regarding how a pentest engagement should be conducted.

• General

  • Is there a specific time frame within which the testing needs to be completed? [Consider the working timeline for the application, avoiding peak usage hours]

  • Are any third-party systems involved in the testing? [e.g., AWS, Azure, GCP systems]

  • What is the testing environment? [e.g., UAT, Production, Development]

  • Are there any defensive solutions in place? [e.g., WAF, IPS, IDS] [If so, consider whether they need to be disabled for testing with appropriate access and credentials]

• Type of Testing

  • Web Application Test

    • How many web applications are included in the scope?

    • What is the purpose of the web application(s) and what functionality do they support? [This helps to understand the application before the assessment and learn about its functionality]

    • Is the application developed in-house or based on an off-the-shelf product (e.g., WordPress)? [If the system uses well-known products, the testing cycle can be significantly reduced]

    • How many unique dynamic functions does the application have? [Dynamic functions are requests requiring user input (either in query or body parameters), such as editing profiles, approving/rejecting transactions, and recovering passwords. This helps estimate the size of the application and the testing effort required]

    • What is the approximate number of input fields? [This refers to the total number of input (query or body) parameters the application handles or an estimate of the average number of input fields per dynamic function, helping to estimate the size of the application]

    • Does the application require authentication? How is authentication handled? Is it self-registration or are accounts exclusively provided?

    • How many user roles does the application have, and how many are in scope? Can you provide a description of each? [e.g., Admin (full privileges), Approver (can approve transactions), Standard User (low privileges). Each role will be assessed for access control and authorization issues, impacting testing time. Descriptions help understand the functionality each role should have access to]

    • How is the application accessed? [It is important to know in advance how access to the application(s) will be provided, e.g., externally accessible, only accessible over VPN, internal network, etc.] [Externally Available/VPN/VDI/IP Whitelisting/Drone/Physical Access (onsite)]

  • API Test

    • How many different APIs are included in the scope?

    • What is the purpose of the API(s) and what type of functionality do they support? [This helps to understand the API before the assessment and learn about its functionality]

    • Does the API require authentication? How is authentication handled? Is it self-registration or are accounts exclusively provided?

    • How many unique API requests are there? [Understanding the number of different API requests helps gauge the size of the API, as each unique request and associated methods will be tested individually. For example, example.domain/api/v1/login, example.domain/api/v1/logout, and example.domain/api/v1/resetPassword would count as three different API requests]

    • What is the approximate number of API request parameters? [This refers to the total number of request parameters the API handles or an estimate of the average number of parameters per request]

    • How many user roles does the API have, and how many are in scope? Can you provide a description of each? [e.g., Admin (full privileges), Approver (can approve transactions), Standard User (low privileges). Each role will be assessed for access control and authorization issues, impacting testing time. Descriptions help understand the functionality each role should have access to]

    • How is the API accessed? [It is important to know in advance how access to the API(s) will be provided, e.g., externally accessible, only accessible over VPN, internal network, etc.] [Externally Available/VPN/VDI/IP Whitelisting/Drone/Physical Access (onsite)]

    • Is there API documentation available? [e.g., Postman collection, Swagger, YAML, flow diagram for the API (especially for authentication requests, if any). Structured and methodical API development typically includes automatic documentation covering every function of the API, including all accepted parameters and expected outputs. This information is crucial during both scoping and testing. Without it, more time may be needed to determine the request structure, parameter names, valid methods, etc.]

Requirements Skeleton 💀

This is a basic skeleton for a requirement list used in scoping a pentest. It provides an overall idea of the solution and serves as a starting point. The checklist must be completed with necessary information. If a field is not applicable to the system, it can be marked as 'Not Applicable' (NA).

• Solution Overview

  • High Level Design of the Solution [A conceptual blueprint outlining the structure, components, and interactions of a system at an abstract level.]

  • Low Level Design of the Solution [Detailed specifications and implementation plans for individual components, providing a granular view of the system's internal workings.]

  • Application Flow Diagrams or relevant documents.

  • Technology Stack for the System [Operating System, Web Services, Database, Programming/Scripting Language]

  • List of User Roles & Corresponding Permission [Access Checking]

• Infrastructure

  • Target IP Addresses

  • Credentials (if needed for White Box)

  • Segregation of Application Server, Database Server

  • Open Ports list; For Database -- SID/Service Name

  • Other IP Addresses (IPS, IDS, Firewalls, Load Balanacers)

  • Information of K8S Cluster

  • Container Images

  • IaCs for the Infrastructure

• Application (Web/API, Mobile Application)

  • Web Application/API

    • URL of the Application

    • User List and Credentials

    • Postman Collection/Swagger File

    • API Documentation

  • Mobile Application

    • APK/IPA [Proxy Enabled -> if you don't want to customize the proxy for the device]

    • Application Link

    • Technology Stack

    • Root Enabled/Unenabled