Penetration testing is security testing in which assessors mimic real-world attacks to find ways around the security features of an application, system or network (NIST SP 800-115). Visionleap Ventures, a Gurugram-based firm, offers penetration testing services in India and worldwide for networks and applications, social engineering tests and physical security assessments, alongside security assessments and SOC as a service.
What Is Penetration Testing?
NIST Special Publication 800-115, the Technical Guide to Information Security Testing and Assessment, defines penetration testing in section 5.2 as "security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network." It often involves launching real attacks on real systems and data, using tools and techniques commonly used by attackers.
The same section notes that most penetration tests look for combinations of vulnerabilities, on one or more systems, that give more access than a single vulnerability would. A test can also show how well a system tolerates real-world attack patterns, how skilled an attacker would need to be, which extra countermeasures would help, and how well defenders detect attacks and respond.
NIST also warns that penetration testing is labour-intensive and carries risk. Systems may be damaged or rendered inoperable during testing. Experienced testers can reduce that risk, but it can never be fully eliminated. For that reason, NIST says penetration testing should be performed only after careful consideration, notification and planning.
Penetration Testing vs Vulnerability Scanning vs Red Teaming
| Activity | What it does | Source |
|---|---|---|
| Vulnerability scanning | Identifies hosts and their attributes, then matches them against a database of known vulnerabilities to flag outdated software, missing patches and misconfigurations. It is highly automated and can have a high false positive rate, so an expert should interpret the results. | NIST SP 800-115, section 4.3 |
| Penetration testing | Mimics real-world attacks to find ways around security features, often by combining several weaknesses to gain more access. | NIST SP 800-115, section 5.2 |
| Red teaming | A group authorized and organized to emulate a potential adversary's attack or exploitation capabilities, to demonstrate the impacts of successful attacks and what works for the defenders. | NIST glossary, citing CNSSI 4009-2022 |
Scanning and penetration testing complement each other. NIST SP 800-115 says that a well-designed programme of regularly scheduled network and vulnerability scanning, interspersed with periodic penetration testing, can help prevent many types of attacks and reduce the potential impact of successful ones. The red team definition above comes from the NIST glossary.
Penetration Testing Services We Offer
Visionleap Ventures offers penetration testing and related assessment in four areas:
- Network penetration testing: NIST SP 800-115 distinguishes external tests, run from outside the network, from internal tests. It describes an internal test as one where testers are on the internal network, behind the firewall, with some level of access, and try to gain more access through privilege escalation.
- Application security testing: For web applications, the OWASP Web Security Testing Guide notes that web applications are almost exclusively bespoke, so penetration testing them "is more akin to pure research", and that automated tools alone can be of poor effectiveness. It also advises that penetration testing should not be the primary or only testing technique in an application security programme.
- Social engineering: testing whether people can be tricked into revealing information. NIST SP 800-115 gives the example of posing as a help desk agent and calling to request a user's password.
- Physical security assessment: NIST SP 800-115 notes that a tester could breach physical security controls to connect to a network, and that security guards should know how to verify that tester activity is genuine, for example through a point of contact or documentation.
When Penetration Testing Is Required: PCI DSS
One standard that requires penetration testing in so many words is the Payment Card Industry Data Security Standard (PCI DSS). The requirements below are those for merchants; service providers have additional requirements (11.4.6 and 11.4.7). Requirement 11.4 of PCI DSS v4.0, as set out in the PCI Security Standards Council's Self-Assessment Questionnaire D for Merchants, includes the following:
- 11.4.1: a defined, documented and implemented penetration testing methodology. It must include industry-accepted approaches, coverage of the entire cardholder data environment (CDE) perimeter and critical systems, testing from inside and outside the network, application-layer and network-layer testing, and retention of results for at least 12 months.
- 11.4.2 and 11.4.3: internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. The tester must be a qualified internal resource or qualified external third party, with organizational independence. The tester does not have to be a QSA or ASV.
- 11.4.4: exploitable vulnerabilities found are corrected according to the entity's assessment of risk, and penetration testing is repeated to verify the corrections.
- 11.4.5: if segmentation is used to isolate the CDE, the segmentation controls are tested at least once every 12 months and after any changes to them.
The PCI Security Standards Council published PCI DSS v4.0.1 in June 2024 as a limited revision with no additional or deleted requirements, and announced that v4.0 would be retired on 31 December 2024. Check the current v4.0.1 text in the PCI SSC Document Library.
If a customer contract or another framework asks you for a penetration test, read its exact wording. Then confirm what is expected with your assessor or customer before you set the scope.
How a Penetration Test Is Scoped
Scoping decides what may be tested, how and when. NIST SP 800-115 (section 6.5) says each assessment should have an assessment plan that sets the rules and boundaries testers must follow. The plan should answer five questions: what is the scope, who is authorized to conduct the assessment, what are the logistics, how should sensitive data be handled, and what should happen in the event of an incident.
- Systems in and out of scope: the plan lists the systems and networks that may be tested, and those that must not be. If a third party owns part of the network, that owner usually must also consent in writing.
- Permitted and prohibited activities: the type and level of testing allowed, and any prohibited activities, stated so they leave no room for interpretation.
- Rules of engagement: NIST defines these as detailed guidelines and constraints for security testing, established before the test starts, that give the test team authority to conduct defined activities without the need for additional permissions.
- Data and incident handling: how test data is stored, sent and removed, and what testers do if they cause or uncover an incident.
- Legal review: NIST recommends that legal advisors always be involved for intrusive tests such as penetration testing.
Scope, methods and reporting are agreed with you before work starts.
What a Good Penetration Test Report Contains
NIST SP 800-115 describes a four-phase model of a penetration test: planning, discovery, attack and reporting. Reporting runs alongside the other three. At the end of the test, a report is generally developed to describe the vulnerabilities found, present a risk rating and give guidance on how to mitigate the weaknesses.
For internal reports, section 8.2 recommends including the test methodology, test results, analysis and a plan of action and milestones (POA&M), so that each vulnerability is matched with specific actions. Because a report may have several audiences, more than one report format may be needed.
The report is a starting point. NIST advises that penetration test results should be taken seriously and the vulnerabilities found should be mitigated. PCI DSS requirement 11.4.4 also calls for repeat testing to verify the corrections. For compliance work, see our guide to SOC 2 and ISO 27001 readiness.