Network segmentation is your blast-radius control. When (not if) something gets compromised, segmentation determines whether the breach stays contained or spreads everywhere. We test whether your boundaries actually hold under hands-on attack.
What is Internal Network Segmentation Testing?
Internal network segmentation testing validates the boundaries you’ve designed between trust zones, security domains, or compliance scopes — the firewall rules, VLANs, and access control lists that are supposed to keep a compromise in one zone from spreading to another.
The test answers a specific question: if an attacker compromised a host on this segment, could they reach hosts on that segment they shouldn’t be able to reach? It’s the only honest way to know whether your segmentation design actually works under real attack conditions.
Why segmentation testing matters more than you think
Segmentation is one of the few security controls that scales — done right, it caps the blast radius of any single compromise. Done wrong, it gives you false confidence: you think compromise of a workstation in marketing can’t reach the cardholder data environment, until a pentest proves otherwise.
The patterns we see repeatedly:
- Documentation drift — the network diagram says VLAN A is isolated from VLAN B, but a firewall rule added in 2019 still allows port 445
- Service account leakage — a backup service account configured for full-environment access, defeating every zone boundary you’ve designed
- Cloud bridge — an EC2 instance that’s authorized for both production VPC and management VPC, creating a path between them
- Monitoring tool side channel — your SIEM or vulnerability scanner has bidirectional access to every zone for visibility, becoming an attack vector itself
- Shared infrastructure — DNS, DHCP, AD domain controllers serving multiple zones with no internal segmentation
Each of these turns a “segmented” environment into a flat one for an attacker who knows where to look.
CyberBullet’s methodology
1. Scope & Architecture Review
We start with your segmentation design — network diagrams, firewall rule exports, AD trust relationships, cloud security group configurations. This defines what should be possible vs. what we’ll test for.
2. Authorized Path Validation
For every documented authorized path between zones, we confirm it works as designed and only as designed. Many “authorized” paths turn out to be broader than expected (e.g., a rule allowing 443 from anywhere when it was meant to allow 443 from one specific source).
3. Unauthorized Path Discovery
We systematically test for unauthorized connectivity between zones — direct (port scan from zone A to zone B), indirect (through a shared service or pivot host), and credential-based (using credentials valid in zone A to authenticate to a service in zone B).
4. Service Account & Privilege Testing
Service accounts are the most common segmentation breakers. We enumerate service accounts in each zone and test whether they can be used to authenticate across zone boundaries — almost always finding at least one that breaks the design.
5. CDE / Sensitive Zone Isolation Testing (PCI 11.4.5/6)
For PCI scope or other sensitive data environments, we run the specific isolation tests required by the standard, with explicit pass/fail documentation per zone boundary.
6. Reporting & Auditor-Ready Evidence
The report is structured for both your security team (with technical detail and remediation guidance) and your auditor or QSA (with explicit test results per documented boundary, methodology disclosure, and evidence per finding).
Frameworks we map findings to
- PCI DSS 4.0 Requirement 11.4.5 and 11.4.6 — segmentation testing
- NIST SP 800-53 SC-7 — boundary protection
- NIST CSF 2.0 Protect (PR.AC) and Detect (DE.AE) functions
- CIS Critical Security Controls v8 — Control 4 (Secure Configuration) and Control 12 (Network Infrastructure)
- HIPAA Security Rule §164.312(a)(1) — access control
Who this is for
- PCI DSS in-scope organizations with cardholder data environments
- Healthcare environments segmenting clinical from administrative systems
- Multi-tenant SaaS providers with customer data isolation requirements
- Organizations post-merger integrating two previously-separate networks
- Companies that have spent significantly on segmentation and want to verify the investment actually works
Our methodology
Every engagement runs through the same six phases. Manual validation isn't a finishing step — it's the product.
Scope & Authorize
We define the engagement boundary precisely before testing starts — in-scope assets, out-of-bounds targets, testing windows, and emergency-stop procedures.
- Written authorization letters exchanged before any packet leaves our infrastructure
- Signal / Slack channel established for real-time findings during the engagement
- Explicit rules of engagement reviewed with legal, IT, and business stakeholders
Passive Reconnaissance
Before a single packet touches your infrastructure, we map your external footprint using public sources only — DNS, CT logs, code repos, internet-wide scan data.
- Typically discovers 15-30% more attack surface than the client originally provided
- Certificate transparency, BGP, and GitHub exposure reporting
- OSINT profile for social engineering vectors if in scope
Active Discovery
We enumerate live services across in-scope assets — ports, software versions, auth mechanisms, and protocol configurations — correlated against current vuln data.
- Hand-tuned scanning profiles — not the default Nessus run
- Protocol-level inspection for TLS, SSH, SMB, Kerberos, LDAP
- Service fingerprinting to ground truth before any exploitation
Manual Validation
Every potential issue is validated by hand before it makes the report. No CVE-dumping. No false positives. This is what separates the engagement from a scan.
- Manual exploitation attempts for any finding of High severity or above
- Business-logic testing on top of the technical layer
- Chained vulnerabilities analyzed as a single attack path
Exploitation & Impact
For confirmed vulnerabilities with attacker value, we attempt exploitation to prove impact — not just that a CVE applies, but what it gets you.
- Proof-of-exploit captured for every confirmed critical finding
- Pivot paths mapped to the actual crown-jewel data
- Interim notification inside 24 hours for anything critical
Report & Remediate
Every finding is paired with severity rated on real exploitability, reproducible proof-of-exploit, and remediation guidance your team can ship this sprint.
- Executive summary and technical deep-dive in a single report
- Findings mapped to CIS, NIST CSF, and relevant compliance families
- Retest included — we confirm the fix before we close the finding
What you walk away with
Frameworks we map to
Findings ship mapped to the control families your regulators and auditors actually check. Governance clients use these crosswalks directly in their program documentation.
- CIS Controls v8
- NIST CSF 2.0 / 800-53
- PCI DSS 4.0
- HIPAA Security Rule
- SOC 2 Type II
- OWASP ASVS
Questions we get asked
How is segmentation testing different from a regular internal pentest?
An internal pentest tests for reachability and exploitability across your whole environment. Segmentation testing is narrower and more rigorous: we systematically test every documented and undocumented path between trust zones, looking specifically for unauthorized connectivity and ways to break out of one zone into another. PCI DSS specifically requires this as a separate test.
Do we need this if we already do an internal pentest?
If you're subject to PCI DSS, yes — Requirement 11.4.5 and 11.4.6 specifically require segmentation testing as a separate exercise. For other organizations, segmentation testing is critical when you've explicitly designed segmentation as a control (e.g., separating dev/prod, separating customer data, isolating legacy systems). It's the only way to prove the design works.
What does 'breaking out of a segment' actually look like?
Common findings: a service account that's allowed to reach both sides of a firewall, an admin laptop joined to the production domain that's also on the office VLAN, monitoring tools with bidirectional access intended to be one-way, or a shared file server bridging two zones that were supposed to be isolated. None of these would show up in a configuration review — only in hands-on testing.
Can we use this evidence for a PCI audit?
Yes. Our reports are structured to satisfy QSA requirements: scope of testing, methodology, results per segmentation control, evidence of testing per zone boundary, and remediation status. We've supported many PCI assessments and our reports have been accepted by every QSA we've worked with.
How often should we test segmentation?
PCI requires annually for in-scope environments, and after every significant change. For non-PCI environments, after any major network change (M&A integration, cloud migration, datacenter consolidation, network refresh) and at least annually for high-stakes environments.