Sunday, 9 February 2014

Data Flow Diagrams and PCI DSS Version 3

I just noticed that the Payment Card Industry - Data Security Standard (PCI DSS) Version 3 has a new requirement at 1.1.3. The old 1.1.3 in PCI DSS version 2 is now requirement 1.1.4 in PCI DSS version 3.

PCI DSS Requirement 1.1.3

So what does new requirement 1.1.3 say?
"Current diagram that shows all cardholder data flows across systems and networks"
The testing procedure for this requirement says
"Examine data-flow diagram and interview personnel to verify the diagram:
  • Shows all cardholder data flows across systems and networks.
  • Is kept current and updated as needed upon changes to the environment.
And finally the guidance says
"Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network. Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices."

The Fundamentals

Data Flow Diagrams (DFD) are a powerful tool in many situations. Whether in the role of PCI QSA or security architect where you are trying to work out the appropriate level of security requirements. This new PCI requirement recognizes this. While PCI really only cares about payment cards, DFDs can and should also be used wherever you are analyzing data which is important to your organization.

A DFD consists of three main sections:
  1. It shows the data flows - i.e. the networks etc. through which data passes.
  2. It shows data storage areas. This indicates where data is stored within the system 
  3. Finally the DFD highlights trust boundaries. This is where data travels across boundaries which are not trusted. The interface to the internet is typically a trust boundary.

A DFD need not be complicated. At its simplest it consists of a series of boxes indicating the data storages on a whiteboard while lines showing where data flows.

When creating a DFD, make sure to ask a series of questions such as:
  • Where are backups held? 
  • How are test systems and data handled. Remember, if live production data is used in a test system, the same level of security must apply as in the production system.
  • Can users export data to desktops etc.?
These questions help build up a complete DFD picture.

When you have a good DFD, then you can start specifying the appropriate level of security controls that are required for each flow and storage within the DFD. For example, if sensitive data flows across the public internet then it should be encrypted using SSL. A DFD helps answer these types of questions.

DFDs and Application Security

DFDs apply when developing applications and choosing security controls. They help working out what type of security controls are required whenever data is at rest or in motion. When developing the security requirements for the application, the development team should develop appropriate DFDs. This should be done early in the development life cycle.  The DFDs can then be used to make sure that the proper security controls are in place which reflect the security drivers for the application. These security drivers can include data protection legislation, PCI DSS, internal corporate policies.

Useful Links

Social: DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot


  1. Good explanation of the requirement, and a good lesson for me!

  2. This is really very nice post you shared, i like the post, thanks for sharing..

  3. For me, the issue of data transfer security isn't so important, much more important is the cycle PDCA and the opportunity to make a presentation quickly. And of course to explain my point of view clearly. The difference is obvious, so it's best to use ready-made templates . The possibility of high-quality visualization is my key to a successful business presentation.