Technical testing
Network Penetration Testing
Most networks are designed as a perimeter with zones behind it. The questions worth paying to answer are what an attacker can reach from the internet, how far they get once they are past the edge, and whether the segment holding your most sensitive systems is really separate from everything else or only drawn that way on a diagram.
- Standard
- NIST SP 800-115
- Viewpoints
- External and internal
- Order
- External first
- Severity scale
- CVSS
- Retest
- Included
Two viewpoints and a boundary
NIST SP 800-115 distinguishes two viewpoints. External testing is conducted from outside your security perimeter, usually as seen from the internet, and looks for what an external attacker could exploit: exposed services, remote access, forgotten hosts. Internal testing works from inside the network, in the position of a trusted insider or of an attacker who has already got past the perimeter, and concentrates on system configuration, authentication, access control and hardening.
The two find different things, which is why neither substitutes for the other. A tidy perimeter says nothing about what a single compromised laptop can reach, and an internal network that is flat behind a good firewall is one phishing email from being an internal problem.
Segmentation testing asks a narrower question with a yes or no answer: can a system in one zone reach a zone it is supposed to be isolated from? It matters most where scope depends on it — a cardholder data environment, a production network kept apart from the corporate one — because if the boundary does not hold, everything on the wrong side of it is back in scope.
We follow the structure SP 800-115 sets out: discovery of hosts and services, vulnerability analysis, then validation by exploiting what was found, looping back into discovery from each new foothold. Findings are rated with CVSS and every one carries the evidence and the steps to reproduce it.
Three tests on three clocks
External, internal and segmentation testing look at different things and change at different rates. Folding them into one annual exercise usually means the perimeter is tested too rarely and segmentation is assumed rather than tested at all.
External network test
What faces the internet changes without a release: a firewall rule, a new instance, a vendor appliance, a newly published vulnerability in software you already run. Quarterly matches the rate at which the answer changes and keeps a finding cheap when it is found.
- Recommended cadence
- Quarterly
Internet-facing hosts, services, remote access and exposed management interfaces
Internal network test
Tests what an attacker could do with a foothold inside: move between hosts, escalate privileges, reach the systems that matter. The trigger that matters besides the calendar is a significant infrastructure change — a new site, a directory migration, a merger of networks.
- Recommended cadence
- Annually, and after significant change
Internal hosts, directory services, credentials, privilege escalation and lateral movement
Segmentation test
Attempts to reach the isolated zone from each zone that should not reach it, and records the result path by path. Cheap relative to the other two and the one most often skipped, even though a scope that relies on segmentation is only as good as the last time somebody tested it.
- Recommended cadence
- Annually, and whenever segmentation changes
Firewall rules, VLANs, access control lists and any isolation your scope relies on
What it will ask of you
A network test depends on an accurate target list and on somebody being able to say what should and should not be reachable. These are the things that decide whether the report reflects your network or only the part of it someone remembered.
A target list you can show you own
IP ranges, hostnames and cloud-hosted addresses, with confirmation that each is yours to authorise. Addresses change hands; testing one that now belongs to someone else is a problem we will not create for you.
A way in for the internal test
A VPN account, a jump host or a small device on the network, and a standard user account. Starting from an ordinary employee’s position is what tells you how much a single compromised account is worth.
The intended segmentation, written down
Which zones exist and which must not reach which. We test against your intent; without it a segmentation test can only report what is reachable, not whether it should be.
A decision about your monitoring
Whether your security operations team is told about the test or not. Told, you get a cleaner test; not told, you also learn whether anybody noticed. Both are legitimate, and the choice is yours to make in advance.
What it is used for
- Evidence for ISO/IEC 27001 and SOC 2, both of which expect technical testing on a defined cycle.
- Penetration and segmentation testing obligations under PCI DSS, where segmentation decides what is in scope.
- Assurance after a significant change: a new site, a data-centre or cloud migration, a merger of networks.
- Answering customer questionnaires that ask specifically about internal as well as external testing.
Not sure this is the standard you need?
Tell us what triggered the question — a customer, an auditor, a contract clause — and we will say which of these applies, including when the answer is none of them.
Where we come in, and where we stop
As with all our testing, we are the assessor: we perform the test, write the report and retest the fixes ourselves, with no third party in between. The impartiality rule that keeps us out of certification does not reach technical testing. What we will not do is test a network design we built for you and present the result as independent assurance of our own work.
Ours
- Scope, rules of engagement and the authorisation
- External, internal and segmentation testing
- Validating findings by exploitation, safely and within the rules
- The report, remediation guidance and the retest
Yours
- Authorising the test and confirming you hold authority over every address in scope
- Owning remediation of firewall rules, patching and configuration, with our support
- Deciding which findings to fix first, on your own risk appetite
How an engagement runs
Testing proceeds only under written authorisation naming the in-scope addresses, the window, the exclusions and the rules of engagement. Denial-of-service and destructive techniques are excluded unless explicitly agreed.
- 01Scope and authorisationWe agree the address ranges, the zones and their intended separation, test windows, escalation contacts and an exclude list of anything that must not be touched. You sign the authorisation.
- 02External testingReconnaissance from public sources, then discovery of hosts and listening services from outside the perimeter. External testing runs first, so the testers have no insider knowledge of your architecture when they do it.
- 03Internal testingFrom the agreed foothold: discovery of internal hosts and services, credential and configuration weaknesses, privilege escalation and lateral movement towards the systems you care about most.
- 04Segmentation testingFrom each zone that should be isolated, attempts to reach the protected zone across every protocol and port, with each path recorded as blocked or open.
- 05ReportingAn executive summary a board can read, and findings with CVSS severity, evidence, reproduction steps and remediation specific to your devices and platforms. Segmentation results are reported path by path.
- 06Remediation support and retestWe work through the findings with your network and infrastructure owners, retest the fixes and issue a retest letter you can give to an auditor or a customer.
What you get from us
- Executive summary written for a non-technical reader
- External and internal findings with CVSS severity, evidence and reproduction steps
- Segmentation results path by path, showing what was blocked and what was not
- Remediation guidance specific to your firewalls, hosts and directory services
- A prioritised backlog your infrastructure team can pick up directly
- Retest of remediated findings and a retest letter for third parties
Common questions
Do we need both an external and an internal test?
Usually, yes. The external test tells you what an attacker can reach from the internet; the internal test tells you what they can do once they are inside, whether through a compromised laptop, a phished account or a malicious insider. Most serious incidents involve the second, and a strong perimeter says nothing about it.
Which should run first?
External. NIST SP 800-115 notes that where both are performed, external testing usually takes place first, so that the testers do not carry insider knowledge of your network into a test meant to show what an outsider could find.
Can the internal test be done remotely?
In most cases. A VPN account, a jump host or a small device you place on the network gives us the same position as an attacker who has got inside. Some environments, such as isolated plant or branch networks, need someone on site, and we will say so at scoping.
What does PCI DSS require?
PCI DSS v4.0.1 Requirement 11.4 requires internal (11.4.2) and external (11.4.3) penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. Where segmentation isolates the cardholder data environment, the segmentation controls are tested at least once every 12 months and after any change to them (11.4.5) — every six months for service providers (11.4.6). The tester must be qualified and organisationally independent, and is not required to be a QSA or ASV, so we can perform these tests. Your QSA reviews the methodology and results.
Will testing disrupt the network?
Testing is designed to avoid it, and denial-of-service and destructive techniques are excluded by the rules of engagement. Some older or fragile devices react badly even to ordinary scanning; where we know of those in advance, they go on the exclude list or are tested in an agreed window.
Ready to scope it?
Send the date you are working to and roughly how large the organisation is. You will get a reply from a practitioner with an honest read on whether the date is reachable.
Related services
Vulnerability Assessment and Penetration Testing (VAPT)
Find what an attacker would find, ranked by what it would actually cost you — and get a report your auditor and your engineers can both use.
Cloud Security Assessment
Review the part of the cloud that is yours to secure — identities, network exposure, storage, logging and keys — against a published baseline and against how an attacker would actually move through it.
PCI DSS Compliance
Get your cardholder data environment scoped, remediated and evidenced for PCI DSS v4.0.1 — before a QSA or your acquirer asks to see it.
ISO/IEC 27001 — Information Security Management
Build an information security management system that survives Stage 2 — and the three years of surveillance that follow.
Related insights
Technical testing
NIST SP 800-115: the four phases, and the one that is not a phase
The four-phase shape behind most credible test methodologies — and the phase that is not fourth at all.
Testing
What a CVSS score does and does not tell you about your risk
A shared scale for technical severity — deliberately context-free, which is exactly why it is not your priority order.
Testing
Your scan is clean. What does that let you tell a customer?
Less than the questionnaire box implies, and the honest answer is still a good one.
