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

Business Risk: Selling AppSec to Business Leaders

Use compliance and reputation risk concerns based on these risk survey findings to persuade management  to invest in your Application Security programs

The table towards the bottom shows the top 25 lists of business risks as given by two different groups. The first list comes from the Lloyd's Risk Index 2011 featuring content from the Economist Intelligence Unit (EIU). The second is slightly older and is taken from the Ernst & Young Business Risk Report 2010.

These show the risks that business leaders are worried about.

What are the risks that can be leveraged to try and improve investment in Application Security programs? There's little point in saying "Guinness Application Security is good for you".  However, we can try to leverage the risks that senior management are worried about.

Compliance and Reputation would seem to be the two main arguments that we can put forward.

Compliance

Both surveys feature "changing legislation" or  "regulation and compliance" towards the top of the risks that business leaders are concerned about.  In our field,  this would include such topics as PCI DSS, Data Protection legislation, HIPAA etc. Our first argument would go along the lines :

• "We need to improve our application security program in order to comply with XYZ"

From my experience PCI DSS is definitely a strong motivator. Some companies realize that they need to comply and are undertaking security initiatives: something that would probably not have happened if PCI DSS did not exist.

Reputation
The other main risk which we can use seems to be Reputation. The Lloyd's Risk index has Reputational Risk at number 3 while the E&Y Business Risk Report has it at number 19. I presented the E&Y table at a recent OWASP Switzerland chapter meeting. The general concensus at that event was that companies are worried about reputation and so the Lloyd's Risk Index placement at 3 is more accurate.

The argument here is:

• "We need to improve our application security program in order to protect our reputation. Look at what happened to SONY, Stratfor, etc...."

Cyber Attacks
The Lloyd's Risk index mentions malicious cyber attacks as risk number 12 and cyber-risks (non malicious) at 19, whereas the E&Y report does not mention them specifically.

	Lloyd's Risk Index 2011	The Ernst & Young Business Risk Report 2010
1	Loss of customers/Cancelled orders	Regulation and compliance
2	Talent and skills shortages	Access to credit
3	Reputational risk	Slow recovery or double-dip recession
4	Currency fluctuation	Managing talent
5	Changing legislation	Emerging markets
6	Cost and availability of credit	Cost cutting
7	Price of material inputs	Non-traditional entrants
8	Inflation	Radical greening
9	Corporate liability	Social acceptance risk: corporate social responsibility
10	Excessively strict regulation	Executing alliances and transactions
11	Rapid technological changes	Inability to innovate
12	Cyber attacks (malicious)	Maintaining infrastructure
13	High taxation	Emerging technologies
14	Failed investment	Taxation risk
15	Major asset price volatility	Pricing pressures
16	Theft of assets/Intellectual Property	Resource scarcity
17	Fraud and corruption	Consumer demand shifts
18	Interest rate change	Global (re)alignment
19	Cyber risks (non-malicious)	Reputation risks
20	Poor/Incomplete regulation	Energy shocks
21	Critical infrastructure failure	Supply chain and "extraprise"
22	Government spending cuts	Managing new business models
23	Supply chain failure	Capital allocation
24	Pollution/Environmental liability	Intermediary power
25	Sovereign debt	Shifting demographics

Summary
Compliance and reputation risks are probably the two main risks to leverage when you are trying to convince management to invest in application security.  This type of approach might seem a bit underhand - but all is fair in love and war.

Links to surveys(PDF):

• Lloyds Risk Index 2011
• Ernst and Young Business Risk Report 2010 

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