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

• PCI Security Standards Council
• PCI DSS Version 3
• Wikipedia: Data Flow Diagram

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Mobile Phone Security Malware Statistics - Mobile Application Security

Which of the following statements do you believe? 

1. "Given that there are around 1.5 billion smartphones and tablets in the world, that means probably fewer than 15,000 of them are harbouring mischievous software." -  The Economist -  November 2013
2. "32.8 Million Android Phones Infected with Malware" - Techlicious.com - April 2013 based on information from NQ Mobile

(As a long time "Economist" reader, I probably tend to go with number 1.)

Does it matter?

If you are trying to make informed decisions around mobile phone security for yourself or your organisation, then it does matter. Go with statement number 1, then you will be trying to implement controls to ensure around the risk that the device will be lost or stolen (encryption, backups etc.)

Favour statment number 2, and you will be thinking more about security controls like anti-virus applications etc.

The Economist article goes on to say:

"Gartner, an information-technology consultancy based in Stamford, Connecticut, advises clients not to worry too much about malware penetrating their networks through the devices employees bring to work. It is the users themselves who are the problem. How, for instance, do companies prevent employees from innocently responding to “spear-phishing attacks” in the form of individually targeted, and very official-looking, e-mail or text messages, apparently from trusted colleagues, that request sensitive information? Security measures need to focus more on educating users, says Gartner, rather than on the relatively minor problem of mobile malware. "

Mobile Application Security

What about mobile application security? The OWASP Top 10 Mobile 2014 risk "M2 - Insecure Data Storage" says about the threat agent:

"Threats agents include lost/stolen phones and the possibility of in-the-wild exploit/malware gaining access to the device."

If you believe The Economist, you will give less weight to the malware risk in your application design and more prominence to the lost/stolen phone risk.

If the device itself is properly encrypted, then you will be less concerned about storing sensitive data on the device. Since the risk of malware is low, then it is unlikely that malware will steal the sensitive data.

(Ok - you should still  be careful about what data your application stores on the device.)

Useful Links

• Sex Lies and Cyber-crime Surveys - Microsoft Research
• OWASP Mobile Top 10 Project

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot