The Art of Scoping – A guide to effective Penetration Testing

Fundamentals

Penetration testing is distinctly different from vulnerability scanning in one crucial way: penetration testing must include an attempt to exploit vulnerabilities and compromise systems. I see clients often consider using low-cost vendors for penetration testing, but the result is usually a glorified vulnerability scan of limited value. I’ll cover how to scope, staff, execute, and consume the results of proper penetration testing to maximize the cybersecurity benefit.

Identifying attack surface

The purpose of a penetration test should be to uncover vulnerabilities and demonstrate attack methods that could be used to compromise the security of your systems. Prioritize which systems to be tested most thoroughly by using risk-based methods. If you have an Information Security Management System (ISMS) then you already have a governance system in place for assessing and treating risk however even if you do not, consider these factors:

• Test where there is complexity: For example, homegrown web applications will have a more complex attack surface than most external networks. You may need to test your external network for compliance reasons, but the real risk may be your application.
• Publicly available information can be used to attack your organization so ensure your testing includes Open-Source Intelligence Gathering (OSINT) to discover infrastructure information, employee passwords from past data breaches, technology used at your organization, and other sensitive information about your environment.
• Test the human element: Testing the ability of people to detect phishing is important but perhaps more important is evaluating threat response capabilities. Do you know what kinds of attacks your systems can prevent? If you can’t prevent certain attacks, are they at least detected? What kinds of indicators did your tools generate from testing? Did your threat response personnel make the right choices and perform the right actions based on those indicators?

Set the Rules of Engagement

Exploitation of some vulnerabilities can cause service disruptions so most penetration testing should treat those attack methods as potential problems to be tested in pre-production. You may feel tempted to conduct testing during off-hours to reduce operational risk however reputable penetration testing firms routinely test highly available systems without issue. Furthermore, if any issues arise it is better to address them when the “first shift” personnel are readily available and able to respond.

Define the Scope

Most penetration testing is time-boxed so the best way to communicate the amount of time a vendor will need for your test is to clearly convey the size and complexity of your environment. Factors that affect scope include:

• Network testing: number and size of networks to enumerate and number of active hosts across all networks.
• Web application testing: number of dynamic endpoints or sessions states possible, number of application roles, input fields, alternative admin interfaces into the same application backend.
• Mobile application testing: number of APIs used (public and private) and number of API endpoints consumed by the app.
• Adversary simulation: number of targets for: spear phishing, phone pretexting, voice cloning and number of sites for physical infiltration.
• Purple Teaming: number of starting points for assumed compromise (endpoint builds), size and complexity of first response team, presence of MSSPs or other outsourced first responders.
• Red Teaming: number of objectives or flags, any actions not allowed or people off limits – the fewer restrictions here, the more real the test.