If segmentation is wrong, everything assessed after it rests on the wrong scope. That is why we validate scope and segmentation before we look at any other requirement, and why a weak segmentation test is never a small finding.
The tester’s own network was let in
An e-commerce payments company relied on segmentation to keep most of its cloud estate out of scope. The segmentation test it supplied had been run from a single jumpbox, on a network the report did not identify, against a sample of sixteen addresses in the cardholder environment. Reachability from one point: nothing more.
Meanwhile, the company’s own console export told a different story. Two peered networks, one belonging to the testing firm itself and one to a data-streaming provider, both classed by the company as untrusted, could reach the container subnet on every port. The cloud platform’s default rule allowing traffic between peered networks had never been overridden. The network policy supplied as evidence took effect eight days after the test. The scope submission also cited a second segmentation test for which no report existed.
Requirement 11.4.5 was not in place. To close it: correct the peering rules, then test from each out-of-scope network, not from one. We also put a network-layer internal penetration test first in the remediation plan, because peered networks reaching the cardholder environment on all ports, and an unapproved service listening on a worker node, are exactly what such a test is designed to find.
Testing the front door while the back door was open
A contact-centre group with sites in five countries had its segmentation test methodology rejected at the end of an annual assessment and had to redo it. The underlying problem had been flagged as critical the year before: shared services, the directory and other critical servers, were not protected from out-of-scope networks, and inbound remote desktop was not restricted. On one site, a personal firewall ruleset allowed access to the cardholder environment from the call-recording platform without multi-factor authentication.
Testing the cardholder environment’s front door while the domain controller next to it is reachable from the user network is not a test of segmentation. If a domain controller is reachable from a network, that network is not out of scope. The internal scans told the same story: they covered 104 of 261 systems on one site and 212 of 760 on another.
How that one ended is worth telling, because it was not our call. The group’s largest customer decided that the risk to its cardholder data from the group was low, and chose thirty-four requirements for us to assess: most of requirement 12, one requirement on access reviews, one on removing access for leavers. No scope identification at all. The customer’s own QSA advised that a letter covering its responsibility, barely mentioning its acquirer’s consent, was the way to go. We think that is wrong. The environment still handles card data whenever the usual automated phone system is not used, in small volumes, but not zero. We said so. Then we were asked to deliver a partial report on those thirty-four controls, and we delivered exactly that, and no more. We do not write the rules. When the people who own the risk choose to narrow them, we say what we think, in writing, and we assess what we were asked to assess.
If a domain controller is reachable from a network, that network is not out of scope.
Segmentation stated, never tested
A payments platform was assessed while still being built. The gap analysis noted that segmentation was “stated to be in place”, and that no test results had been provided. The first Report on Compliance then listed flaws in the segmentation testing methodology as one of the reasons scope could not be validated, alongside network diagrams that changed during the assessment. Scope and segmentation had to be validated before any other requirement was assessed. The compliant report followed two months later, once the platform was running and the test had been done properly.
What people get wrong
They treat a reachability check from one point as a segmentation test. The requirement asks for isolation from each out-of-scope network. One jumpbox on one network answers for one network.
They forget cloud defaults. A peering plus a default allow rule quietly undoes the diagram. The diagram shows isolation; the console shows every port open. The console is right.
They test the perimeter and ignore the shared services. The directory, the monitoring platform, the backup server and the management tools sit on both sides of every boundary. If they are reachable from an out-of-scope network, the boundary is a line on a slide.
They supply a policy dated after the test. The test proves the state of the network on the day. A rule that took effect the following week was not tested.