The beginners guide to Planning Penetration Testing Projects

With more than 20 years of expertise in information and cyber security, our team has actively supported various organisations of varying shapes, sizes, structures, and maturity levels across multiple industry verticals. During our extensive experience, our scoping team has identified several recurring themes that project teams commonly face challenges with when beginning to define the scope of a penetration testing project and agree on a set of required target insights and outcomes.

TL:DR – This article is designed to be foundational and help project teams and required stakeholders understand what needs to be considered when planning a penetration test:

WHY are we testing?

Why has Penetration Testing been chosen as our method of evaluating risk? What are the driver and objectives for the assessment and why does Pen Testing achieve this?

WHAT are we testing?

What is the defined boundary of the scope that needs to be agreed and assessed to capture our requirements and provide required insights.

HOW are we planning to conduct testing?

Is testing going to be performed in-house via internal resources or automated testing tooling? Does the assessment need to be carried out via a specialist 3rd Party supplier under a defined methodology?

WHO needs to be involved in the scoping and planning process for testing?

And what internal and external resources need to be involved to deliver the proposed assessment to ensure requirements are met?

WHERE are the systems/assets that require assessment located?

Are the services hosted within our infrastructure or premises? Are they hosted/managed via a third-party supplier? Are the services multi-tenant and managed within a shared responsibility model? How will a tester access the in-scope assets?

Within this article, we’ll discuss qualification and planning criteria that your organisation should include within your planning phase to ensure your Penetration Testing engagements run successfully on time and within budget and more importantly, provide an effective return on your investment.

Why do we need to perform a Penetration Test?

Often during customer meetings and discovery calls we ask this question and receive various example responses back such as:

• “Our customer has asked us to provide a Penetration Testing report as part of their due diligence prior to signing our contract/MSA”
• “We need to understand how secure we are as a business”
• “We need to provide a certificate to a supplier/prospective customer as part of a tender or RFP response”
• “We’ve recently built a new platform and need to understand if there are any security vulnerabilities”
• “Our ISO27001 Auditor/PCI QSA told us we had to perform a pen test as part of our compliance obligations”
• “We want to understand threats to our business-critical infrastructure and application services”

It is important to remember that Penetration Testing is a point-in-time vulnerability measurement activity that is solely focused on a security consultant identifying security issues.  Providing you with a contextualised set of findings relevant to your business, your organisation’s risk level and a set of remediation actions.

If you would like:

1. a) An independently performed holistic assessment of how your organisations security controls compare to an established compliance standard or security framework.
2. b) To perform ongoing security assessments on a frequent basis to understand if assets are vulnerable to known security flaws.
3. c) To provide a certificate to a separate entity to demonstrate compliance against a defined data security standard.
4. d) To build a repeatable internal security assurance process to help define and understand risks prior to performing any risk assessment/testing activities.

You may be better suited to looking at exploring conversations around other types of risk assessment services such as:

• Cyber Security Maturity Assessments (CSMA) or Security Control Framework Gap Analysis or audit activities.
• Automated Vulnerability Scanning or Hybrid Testing as part of a subscription based model, Continuous Security Testing or Managed Penetration Testing service.
• To look at aligning against defined information security certifications such as Cyber Essentials, ISO27001, IASME Cyber Assurance or looking to align against renowned security control frameworks such as the NIST Cyber Security Framework, NCSC Cyber Assessment Framework or CIS implementation groups.
• To consider working with a security assurance specialist to discuss looking at a Threat Modelling exercise with associated internal stakeholders to clearly define and understand your organisations risks.

What should we include within the scope of our Penetration Test?

Getting a clear answer to this can often be difficult and is something we often get asked in initial meetings and discovery calls with the answer typically being, “it depends”. When defining the scope of a penetration test stakeholders typically need to consider:

What is the driver for the test and what are our specifically required outcomes or objectives?

For example, if the assessment is required as part of a defined compliance driver such as PCI DSS, ISO27001, NHS DSPT, SWIFT CSP or NCSC IT Health Check. The compliance standard may dictate the systems which must be included in scope and types of testing that need to be delivered within a defined test specification or requirements brief.

If a test isn’t being performed in line with a specific compliance driver, the project team should look to understand:

• Are we looking to determine if specific objectives are achievable within the timeframe of the assessment- e.g. understand data exfiltration risks, testing of permissions and access controls, testing of implemented segmentation in line with strategy.
• Are we looking to confirm if systems are hardened in line with industry best practices like OWASP Top Ten, CIS benchmarks, NCSC best practices etc.
• Are we looking to achieve a security baseline of a specific target asset or system.
• Are we looking to provide a customer or stakeholder with external validation of the security of a specific asset or system.

This will have an impact on the methodology that your internal team or delivery partner will adopt, and the reporting requirements you may have following completion of the assessment.

What systems are we looking to include within the scope for testing?

Some examples of systems typically included within a Penetration Test are:

• Desktop, Mobile or web applications
• Externally facing infrastructure services (Hosted either on-premises, or in the cloud)
• Web services (e.g. REST/SOAP API services)
• Cloud tenancies and subscriptions (e.g. Microsoft 365, Microsoft Azure, Amazon Web Services etc)
• Internal infrastructure services and network devices (Either on-premises or virtually hosted)
• Wireless networks
• Social engineering of users (either via email, telephone or SMS)

When defining your scope for assessment it’s often useful to understand how users access these services, who provides these services on behalf of your organisation and how permissions and access control are managed for these systems, helping you to define a set of desired test outcomes and objectives.

How are we going to perform a Penetration Test?

When working with suppliers in the information security industry the term “Penetration Test” is often used by marketing teams as a broad descriptive term but not always in the specific context that an organisation requires.

The National Cyber Security Centre (NCSC) defines a penetration test as “A method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might”. So does this need to be delivered via an independent qualified security consultant? The use of automated testing tools delivered in-house? A combination of both? Again- it depends on an organisation’s requirements.

When delivering penetration testing services, the approach used to deliver testing is often dependent on:

Does the test need to be performed via an accredited or certified supplier to meet compliance standards or procurement or tender requirements?

Compliance driven requirements like PCI DSS 11.3 or the NCSC’s CoCo IT Health Check requirements are good examples of compliance driven testing requirements which either recommend or stipulate that testing must be performed by a CREST or CHECK accredited third-party penetration testing services supplier. Procurement requirements can typically vary based on the industry and regulatory requirements of that organisation.

Does the organisation require a third-party delivered manual penetration test of a specific asset or system or can this be performed in house?

For scenarios where testing is performed as part of internal risk assessment activities or for best practice. It may be possible for testing to be performed in-house by an internal security tester, or automated tooling. However, it is important to make sure that objectives are clearly understood and that the assigned practitioner is appropriately skilled in testing and auditing the in-scope assets or systems.

In some scenarios there are benefits to performing testing of non-complex systems in-house and working with a trusted security testing partner as an extension of your team to provide assurances for more complex testing requirements.

Once you have defined your specific drivers and what you need to test, you can begin to work with an external supplier, or internally discuss testing methodologies and design an approach that provides you with the right level of visibility for your objectives and frequency that you require testing to be performed. For example:

a) Manual Penetration Testing

This approach is useful for providing a comprehensive point in time assessment of a specific asset or system to provide a contextualised report of any identified security risks or vulnerabilities for an organisation. To provide an insight into how a threat actor would attempt to target a specific asset or system.

Whilst comprehensive, delivering manual penetration testing frequently can be considered expensive if being delivered by an external third-party supplier or appointed internal subject matter expert and can be difficult to accommodate in information security budget constraints for requirements where frequent testing is needed.

b) Automated Vulnerability Scanning

This approach utilises automated security testing tooling to test a target asset or system for known security flaws or vulnerabilities. Whilst automated testing can emulate certain attack techniques used by ethical hackers, it should not be seen as a direct replacement since some attack techniques currently cannot be replicated by automation.

Automated testing is useful for testing assets that require frequent assessments and can be managed either internally by project team members or via an external third-party supplier where resource bandwidth is a challenge, or an organisation would benefit from working collaboratively with a subject matter expert.

Automated testing is commonly used for testing of assets hosted within environments which regularly change, such as a web application software development lifecycle (SDLC).

c) Combination of automated and manual testing/hybrid testing

This approach is most commonly used by organisational security teams who are looking to regularly perform comprehensive testing of business-critical systems and assets for security flaws and vulnerabilities. Typically focusing on testing of assets or services that are considered high risk.

By using a combination of threat modelling, automated tooling and subject matter expertise organisations can focus assigned security consultant testing time on testing attack vectors that automated tooling cannot replicate efficiently. Maximising technical return on investment and helping organisations to reduce their Mean Time to Detection (MTTD).

Who should be involved in our scoping process for Penetration Testing?

The project team members and personnel involved in scoping a penetration test will often vary based on the systems defined in the scope for testing and the driver for the assessment. But typically, a well-planned scoping process should involve all required risk stakeholders where possible and endeavour to understand:

• Does this person/third-party supplier possess knowledge on the required engagement objectives/insights/compliance drivers we need to capture with this requirement?
• Does this person need to communicate the findings of this engagement to technical and non-technical stakeholders both internally and externally?
• Does this person possess knowledge on the technology stack in use and architecture/design of any proposed environments or assets that require assessment during the engagement?
• Does this person have a key role in managing change control requests for management of any of the environments/assets in scope for the assessment?
• Does this person/organisation require authorisation to test to be requested, provided and approved prior to any security testing activities commencing?
• Does this person/team have a role in remediating/mitigating any findings identified from the engagement?

By understanding resource requirements within the initial planning phase of an engagement this allows us to ensure scoping activities are efficient and work collaboratively with internal teams or suppliers where needed.

Where are the systems that require testing located and how do we access them?

When performing initial scoping activities its vital that internal project team members and third-party suppliers clearly understand the location that in scope assets are hosted/accessible, how access for testing can be provided and the status of the environment that requires testing.

To ensure that:

• You as an organisation legally understand what can be included within the scope of your security testing activities. E.g. not testing third party Software as a Service (SaaS) services that you do not own or have appropriate consent to test.
• That no disruption to intended users or customers is experienced and appropriate planning precautions can be taken.
• That valid authorisations are sought from any internal system owners or third-party suppliers to ensure that your internal team is not in breach of applicable law.

When referring to the location of an asset, common examples include:

• On-Premises/On-Site deployments- This may either be physically within your organisation’s offices, or an external secure facility like a data centre.
• Cloud Hosted in a Public/Private/Hybrid Cloud- Hosted either by your organisation or a third-party supplier within a provisioned tenant such as Microsoft Azure or Amazon Web Services (AWS).
• As part of an Infrastructure as a Service (IaaS), Software as a Service (SaaS), Platform as a Service (PaaS) subscription model provided via a third-party supplier or service provider.

Traditional examples of environments that are included within Penetration Testing engagements are:

• Live/Production environments- The live business environment used by customers.
• User Acceptance Testing (UAT)/Staging/Pre-Production environments- An environment specifically configured for building and testing software prior to promotion to production. This environment is typically a replica of the live environment but is used for testing purposes such as security testing, functional testing, load testing or user experience testing.
• Development environments- An environment specifically configured for ongoing development of software, applications or infrastructure services.

Typically, when performing security assessment activities like Penetration Testing it’s recommended that testing of live environments is avoided wherever possible.

This ensures that business operations can continue to operate uninterrupted and that risks to live databases, software or services can be discussed and mitigated accordingly.

Conclusion

Hopefully, this helps you and your project team to understand and define your requirements both for internal testing requirements or third party driven testing needs.

If you would benefit from having access to a template requirements brief and our more comprehensive Secarma Penetration Testing Guidance document, or you have a specific security assurance or security consultancy challenge that you would like some support with please contact one of our cybersecurity experts today who will be happy to assist you.