A Red Team’s Perspective: How to Scope a Penetration Test

Penetration testing is a crucial part of a comprehensive cybersecurity plan. By simulating a real-world attack, a penetration test can help identify vulnerabilities and weaknesses across systems, networks, and applications before a malicious actor can exploit them.

To get off on the right foot with a penetration test and get an accurate timeline and budget for the test, it’s important to have a proper scope. Learn how to scope a penetration test from the perspective of the Sedara Red Team.

Define your Objectives

What are you aiming to achieve in your penetration test? This will help you define the rest of the scope.

Here are some examples:

• Assess the overall security posture and maturity of your organization
• Test your IT department’s ability to detect and respond to incidents
• Test the effectiveness of current technical security controls, like EDR and IDS
• Check over your network after recent changes to ensure no weaknesses were introduced
• Assess the security of a new acquisition, vendor, supplier, or partner
• Validate compliance with frameworks or regulations like PCI DSS, HIPAA, or NIST
• Enhance risk management efforts by identifying potential risks

Knowing your objectives and communicating them to the penetration testing team can help in customizing the test and ensuring that it achieves the objectives that are most important to help you secure your organization.

Identify Targets

Targets are the parts of your network and services you want the penetration testing team to focus on. Here are some examples of targets you may choose for your scope:

• Domain names, IP addresses, or IP address ranges
• Web applications
• Wireless networks
• People (in the case of tests that include social engineering)
• Facilities (in the case of physical penetration testing)

It is better to use domain names than IP addresses, because dynamic IP addresses can change before or during the test, generating confusion and wasted time.

Black, Grey or White Box?

In a “black box test”, an organization provides a penetration testing team limited information, like a domain name, to test. However, this will not always provide the highest quality test.

As an example, if the organization’s efforts have been focused on securing the part of their network that faces the Internet, the penetation test may not show any vulnerabilities. But it will not show vulnerabilities accessible only from the inside of the network. A malicious insider or successful attacker who does breach the network can then exploit those vulnerabilities.

As a result, some organizations will do a “gray box test” – provide a penetration tester with some knowledge or access to the network. This allow the tester do attacks from dual sides of the network  – simulating one attack as an Internet user, and one attack as an internal user or compromised account. Additionally, they allow for a more targeted assessment by making the testing process more efficient.

Similarly, in a web application, it may be helpful to give a penetration tester one or more usernames with differing levels of access to check for possible privilege escalation or other internal attacks.

The information provided to the penetration tester should be fully agreed upon beforehand.

In a “white box” penetration test, the tester is provided with as much information as possible about the workings of the network or application, and usually a high-level administrative account. This is more typical in thorough application testing, where mapping and code review of the web application can be time-consuming without transparent access.

Establish Rules of Engagement

Clear Rules of Engagement (ROE) can help a penetration test run smoothly. ROE defines the boundaries of the test, including:

• Permitted or restricted testing techniques
• Testing schedule – for example, you may want to ensure tests are run during business hours, so that IT support is available. Or you may want to preserve network bandwidth by limiting testing to certain hours or days.
• Critical applications or systems that cannot be out of service under any circumstances
• Applications, data or systems that should not be accessed or tested

If you exclude any specific tests, data or systems from your penetration test, carefully consider why you’re excluding them. If it’s because your network or application has a low resilience for downtime, or a high requirement for privacy, those are arguments for penetration testing as part of a plan to secure critical services! Remember, a real attacker will not respect your scope. Hesitation to allow a penetration test may signal a need to improve business continuity and defense-in-depth, or to create a test environment (which can also be used for patch testing).

Define the Criteria of Success

For most penetration tests, the tester will have the same criteria for success as a real-world attacker: to compromise a high level of access and the most valuable data. For most penetration tests, this is enough of a goal, and allows the penetration tester the freedom to perform a quality test.

However, some organizations may have specific criteria in mind for a penetration test, especially when testing a web application. Here are some examples:

• Gaining administrator privileges on the network (like Domain Admin in Active Directory)
• Finding as many vulnerabilities as possible
• Checking for specific vulnerabilities, like the OWASP Top 10
• Gaining access to specific critical servers or networks
• Performing privilege escalation within an application
• Gaining access to a specific database or set of data

Defining these goals with your penetration testing team can help them focus their efforts.

Find out how Sedara help you improve your cybersecurity today with a penetration test.
Contact us!