Peter Hall
January 4 2024
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.
Often during customer meetings and discovery calls we ask this question and receive various example responses back such as:
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:
You may be better suited to looking at exploring conversations around other types of risk assessment services such as:
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:
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:
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.
Some examples of systems typically included within a Penetration Test are:
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.
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:
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).
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:
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.
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:
When referring to the location of an asset, common examples include:
Traditional examples of environments that are included within Penetration Testing engagements are:
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.
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.