A number of years ago, I wrote a post on how to diagram for your QSA. While my original post still has validity, there have been a few changes have occurred so I thought it was a good time to update everyone so that diagrams meet what your QSA needs for documentation.
One of the changes that came with v3 of the PCI DSS was with requirement 1.1.3 that now explicitly calls out that the data flow diagram be overlaid on the network diagram. The purpose of this was twofold. First, such an approach allows the organization being assessed to further refine their scope for their PCI assessment. Second, it allows the QSA an easier time to confirm that the scope of the PCI assessment is accurate.
Prior to v3, organizations had a tendency to deliver data flow diagrams that had no basis in reality as to how they were physically implemented. A lot of this was due to the fact that developers and networking types never communicated between one another. As a result, QSAs would hear comments such as, “All I know is it just works”, “You’ll have to ask the developers …” or “You’ll have to ask the networking people …”. This obviously resulted in a lot of discussions (i.e., arguments) over scope accuracy between QSAs and their clients. Under the new v3 requirements, hopefully all of those discussions will go a lot easier and faster.
Regardless of what requirement 1.1.3 states, QSAs are still encountering data flow diagrams that look more like cubist or surrealist paintings. This situation seems to be driven by the fact that a lot of organizations either do not want to or cannot get their developers and networking folks together to come up with a data flow diagram that can marry up to the network diagram. Let me tell you that going through this exercise greatly reduces the issues surrounding scope because scope becomes very clear once everyone can “see” how data flows through the network. However, it is not surprising when organizations come back and say they found the exercise too daunting. Lots of organizations operate in such a siloed structure, that: (1) it takes an act of God to get everyone necessary together for such a discussion, (2) everyone agrees on the flows and networks used and (3) somewhere there is a flow that no one knows about or knows how it works. All of this can be resolved, but it takes time and information to work out and can end up being incredibly tedious particularly in a complex environment.
Unfortunately, while the scope becomes much clearer once the dataflow is overlaid on the network, the scope also tends to end up much larger than anyone realized. That is because systems that were thought to not have any connectivity (Category 3) to the cardholder data environment (CDE) end up as connected systems that could impact or influence the security of the CDE (some form of Category 2). It is then that there is a “mad dash” to minimize the number of these systems that need connectivity, i.e., reduce scope. It is during these scope reduction efforts that we encounter twisted and contorted arguments regarding systems that are clearly in-scope, but the client does not want to be in-scope and will do anything and everything imaginable to remove them from scope. Some of these discussion become so tortured in their logic as to be laughable, e.g., “Can’t we just ignore them?” and my personal favorite, “If I paint these servers “blue” will they then be out of scope?”.
But to further confirm scope, v3 introduces us to a revised requirement 11.3 that went into effect on July 1, 2015. As part of that change, the penetration test methodology now requires that the penetration testing exercise prove that network segmentation is in place as documented and therefore further prove that the scope for PCI compliance is accurate. This basically requires the penetration tester to confirm that your network diagram overlaid with the dataflow in fact fully documents your organization’s scope for PCI compliance. Therefore, if your dataflow and network diagrams are junk, do not be surprised if your penetration tester and/or QSA come back and tell you that your scope is larger than you thought.
Behind the scenes, there has been a change made by the PCI SSC through their reviews of QSAs’ ROCs under their quality assurance program. The Council is concerned that the diagrams put in ROCs are not always legible to readers. While organizations provide the original diagrams, the Council wants diagrams in reports to be legible for the banks and processors when they review the reports. As a result, QSAs and ISAs have been informed that their ROCs need to break out or section large diagrams so that they are legible on standard paper (i.e., 8.5”x11” or A4). As a result, a lot of ROCs are exponentially increasing in size to accommodate the network and data flow diagrams that now require many additional pages to ensure that the diagrams are legible in the ROC.
This should bring us all back up to date on network and dataflow diagrams.
PCI Guru 