Planning and Scoping practice questions

The test will include social engineering of remote employees

Why wrong: Social engineering is not mentioned in the scope and is not directly related to the exclusion of cloud and branch infrastructure.

The test can only be performed during off-hours

Why wrong: Off-hours testing is a scheduling detail, not the primary concern regarding scope coverage.

The tester will require VPN access to the corporate network

Why wrong: VPN access is a technical requirement but does not address the risk of excluding cloud and branch systems.

Ensuring all testing is performed from a single external IP address

Why wrong: This is an operational or technical consideration, not a legal one.

Obtaining explicit written authorization from each country's legal department

Why wrong: While authorization is important, it is not the most specific legal requirement; GDPR compliance is a broader and critical regulation.

Restricting testing to non-business hours to minimize impact

Why wrong: This is a scoping decision about timing, not a legal requirement.

Add the microservice to the test and include it in the final report as an unadvertised finding

Why wrong: This bypasses the formal scoping process and could lead to legal issues or invalidate the test's authorization.

Decline the request because the microservice was not part of the original scope

Why wrong: While declining is a possibility, it is not the best first action. The tester should first discuss the request with the client to understand their needs and potentially adjust the scope formally.

Test the microservice only if it is using the same technology stack as other targets

Why wrong: Technology similarity does not grant authorization. The scope must be agreed upon in the ROE regardless of technical similarities.

The client's headquarters location determines which laws apply

Why wrong: Laws often apply based on where the data subject or system resides, not solely the company's headquarters.

All findings must be reported in the local language of the country of operation

Why wrong: While language may be a practical consideration, it is not the most critical legal requirement regarding data privacy and handling.

The penetration testers must be citizens of the country where the systems reside

Why wrong: Citizenship requirements are not typical for penetration testing; however, work permits or local legal entities may be relevant, but data handling usually takes precedence.

The on-premises systems are more critical, so testing them is sufficient.

Why wrong: This ignores the risk exposure of cloud assets and does not provide a complete security posture assessment.

Cloud systems are generally more secure and do not require testing.

Why wrong: Cloud environments are still susceptible to misconfigurations and vulnerabilities; they should be tested.

Testing cloud systems would violate the shared responsibility model.

Why wrong: Cloud penetration testing is allowed and commonly performed within the boundaries of the shared responsibility model with proper authorization.

Statement of Work (SOW)

Why wrong: The SOW outlines the general objectives and deliverables, but not the specific regional restrictions.

Data Processing Agreement (DPA)

Why wrong: A DPA governs how data is processed and protected, but does not define which systems are in scope for testing.

Penetration testing methodology document

Why wrong: The methodology describes techniques and procedures, not the scope or legal boundaries.

That cloud services are often the most vulnerable and should be included for a thorough test

Why wrong: While this may be true, the primary message should be about the limitations of the assessment rather than asserting cloud vulnerability.

That the client can always test cloud services later in a separate engagement

Why wrong: This shifts the issue but does not address the immediate scoping concern; it may be a secondary option.

That compliance concerns are unfounded and the test should proceed anyway

Why wrong: Dismissing compliance concerns is unprofessional and could lead to legal issues; tester must respect client constraints.

A limitation of liability clause

Why wrong: While liability limitation is common, it is not as critical as ensuring compliance with data protection laws, which is a legal requirement.

A non-disclosure agreement

Why wrong: NDA is important for confidentiality but does not specifically address data protection requirements under GDPR.

A schedule of testing hours

Why wrong: Testing hours are operational details, not a legal consideration for data protection.

White-box test

Why wrong: A white-box test provides the tester with full knowledge of the environment, including credentials and source code.

Gray-box test

Why wrong: A gray-box test provides limited information, such as login credentials or network architecture, but not full internal knowledge.

Covert test

Why wrong: Covert testing refers to the tester's identity being hidden from the organization, not the level of knowledge provided.

The need to test on-premises systems as well to get a complete picture

Why wrong: While true, the client specifically requested only cloud testing; the immediate concern is defining what in the cloud is in scope.

The potential for false positives in cloud vulnerability scanners

Why wrong: False positives are a consideration but not the primary scoping issue for defining boundaries.

The cost of third-party cloud penetration testing tools

Why wrong: Cost is a budget consideration, not a scope boundary issue.

Detailed network diagrams of the cloud environment

Why wrong: Since cloud assets are out of scope, diagrams of that environment are not necessary and may cause confusion.

Approval from the cloud service provider

Why wrong: While some cloud providers require notification, the primary concern in the ROE is defining in-scope versus out-of-scope assets.

A list of all cloud API endpoints

Why wrong: API endpoints are not relevant if cloud assets are excluded from testing.

Scope

Why wrong: Scope defines what is tested, not restrictions.

Scheduling

Why wrong: Scheduling covers timing windows, not restrictions.

Legal

Why wrong: Legal covers data handling and liability, not specific restrictions on techniques.

The list of operating systems used in the cloud

Why wrong: Useful but not the most critical scoping issue.

The public IP addresses of the cloud servers

Why wrong: Part of scope but not the most important legal/permission issue.

The budget allocated for cloud testing

Why wrong: Budget is separate from ROE.

Vulnerability scan report

Why wrong: This is an output of testing, not a pre-engagement document.

Penetration test report

Why wrong: This is the final deliverable after testing is complete.

Risk assessment matrix

Why wrong: While useful for scoping, it is not the critical legal document that authorizes the test.

Test the cloud assets as part of the engagement because they support the client's business

Why wrong: Testing without authorization from the provider is unauthorized and illegal.

Test only the client-facing parts of the cloud service

Why wrong: Even client-facing parts are owned by the provider; testing them without permission is still unauthorized.

Request the client to sign an additional liability waiver for testing third-party assets

Why wrong: A waiver does not grant permission from the cloud provider; the tester must have explicit authorization from the asset owner.

Begin testing the API because it is part of the client's environment

Why wrong: This is incorrect because testing a third-party service without authorization is illegal and could breach contracts.

Only test the client's internal systems, excluding the API

Why wrong: This ignores the client's requirement to test the API; if permission can be obtained, it should be included.

Use the payment processor's sandbox environment without notifying them

Why wrong: Even sandbox environments are subject to terms of use; unauthorized testing is still not allowed.

Non-Disclosure Agreement (NDA)

Why wrong: The NDA protects confidential information but does not define technical constraints or scope boundaries.

Penetration Testing Report

Why wrong: The report is delivered after the test and contains findings, not pre-test constraints.

Scope of Work (SOW)

Why wrong: While the SOW outlines high-level objectives, the detailed constraints are typically included in the ROE.

Statement of Work (SOW)

Why wrong: The SOW describes the work to be performed and deliverables, but it does not typically detail specific technical restrictions like excluding a CDN.

Non-Disclosure Agreement (NDA)

Why wrong: The NDA is a legal agreement regarding confidentiality, not technical scope or restrictions.

Master Services Agreement (MSA)

Why wrong: The MSA outlines long-term business terms, liabilities, and payment, but not per-engagement scope exclusions.

Exclude the HR department's IP range from the test

Why wrong: Excluding the HR range would violate the client's requirement to test all IP ranges and could leave critical systems unassessed.

Use only passive reconnaissance techniques on the HR systems

Why wrong: Restricting to passive techniques would limit the depth of the test and likely miss vulnerabilities that require active testing; it does not fully meet the test requirement.

Include the HR systems but require written authorization from HR management

Why wrong: While authorization is important, it does not address the potential for business disruption; additional scheduling precautions are needed.

The tester must exclude all API endpoints from testing.

Why wrong: Excluding all API endpoints would leave the APIs untested, which is not aligned with the client's goal.

The tester must coordinate testing schedules with the API vendors.

Why wrong: While coordination may be useful, the primary concern is the testing approach; many APIs may not require vendor coordination.

The tester must provide a list of all API calls to be made prior to testing.

Why wrong: Providing a list of calls may be part of the planning but does not address the operational risk of disruption.