Data Flow Diagrams and Security Requirements

High Level Diagram

Updated: June 1st 2012

Dataflow Diagrams (DFD) can be really useful in helping you specify your security requirements when starting on a new web development project. Although there is a whole literature around the use of DFDs, you don't necessarily have to do anything fancy or complicated. Use simple boxes to show where data will be stored  and lines to indicate where data flows.

Before embarking on the DFDs, classify the type of data that you will be processing. Is it personal data, payment card data etc.?

Draw the DFD diagram at a fairly high level. It should contain boxes to indicate where data will be stored, and then lines between the boxes to indicate the data flows. Include any other important components such as end-users or other devices.

Simple Use Cases or stories will help you work out where data will be stored and where it flows.

An important concept is that of Trust Boundaries. This is where data comes from someplace or goes somewhere which you don't inherently trust. The internet is one obvious place - but it can also be within your own organisation. Data is coming from a different department, and you don't necessarily trust the data that they transmit.

High Level Diagram - with simple DFD

When you have drawn the diagram, then begin to look at security related issues. Threat Modelling is often used to help work out the security risks that you need to address. An issue with formal Threat Modelling is that it can be a relatively complicated technique. It is easy to lose sight of what you are trying to achieve. However, if you or your organisation are familiar and comfortable with the concept of Threat Modelling, then use it.


For the purposes of this exercise I am going to concentrate on a checklist or question based approach.

Data Stores

Your DFD will show where data is stored. For each of these locations ask the following types of questions. The answers will depend to an extent on the Data Classification of the information.

• Do we need to store the data here? Ideally, data should be stored in as few places as possible. So, for example, if your DFD indicates that data is going to be stored on an external USB stick or a laptop, this should raise a red flag.
• Do we need (all) this data? In some cases you may be storing excessive amounts of data. Data Protection Legislation requires that you only store as much information as you need.
• Do we need to take special measures to protect this data?   If you are processing data which falls under Data Protection Legislation then you would need to encrypt any data which is stored on portable media, such as USB sticks or laptops. For payment card information, you would need to protect data in a manner as set down by the PCI DSS standards.
• Who should have access to the data?  
• How do you control access to the data?  
• How do you monitor access to the data?  
• How long does the data need to be retained for?    
• What happens to devices at the end of their life cycle?  Devices which store sensitive or confidential information should be securely destroyed at the end of their life. Otherwise they might end up being advertised on ebay.

Data Flows

The next step is to look at data flows using similar types of questions. Of particular importance here is whether data flows across trust boundaries. You should have indicated these in your DFD.

So these are the types of questions for the data flows.

• Do you need to protect the confidentiality of the data?   If data is flowing across the trust boundary, such as the internet, then you will need to protect the data. Typically you will use technology such as SSL or its more modern variation, TLS.
• Do you need to protect the integrity of the data?   Maybe we need to check digital signatures on the data to make sure that it has not been tampered with.
• Do you need to validate the data?   Implement data validation etc., Using the techniques outlined in the OWASP Top 10. If it crosses a trust boundary then data validation should be used.
• Do we need all this data?   If the data contains excessive information, then delete the excess.
• How was the source authenticated?   If the information is crossing a trust boundary, then we need some mechanism to confirm the identity of the sender. Typically some sort of logon mechanism is used for authentication.
• Are there any other measures which are necessary?  For example, to prevent message replay or message deletion.

Document your answers to the above questions. They should help you specify the security requirements that your application will need to meet. For example, now you should have a better idea of where you need to encrypt your data, perform validation, authenticate the user etc.

Some Gotchas

There are a number of areas where you need to be careful. Typically, these are the areas where data may be stored and you haven't thought about it.

Where is your backup stored? If it is stored externally, then you may need to think about mechanisms such as encryption.

Do you plan to use copies of your live production data in your test environment? Remember, that even though it's being used in the test environment, it still is live data and should have the same level of protection applied to it.

Do you write data to application log files or other similar type locations? You should make sure that this functionality is disabled on production systems.

Do you write sensitive data to your audit trail? Make sure not to write sensitive information such as passwords, names and addresses etc to your audit trail.

What about troubleshooting? Situations will arise where you need to extract production data to assist in troubleshooting. This could mean enabling application logging, or copying files to other systems where it can be analysed. You should have procedures  in place to make sure that this information is deleted when the troubleshooting has been completed. Also disable any logging which you may have turned on during the troubleshooting.

Conclusion

Data Flow Diagrams (DFD) are a useful tool in helping you specify the security requirements that your application needs to meet. The approach shown here is relatively simple and informal. In particular, it does not use Threat Modelling techniques to analyse your risks. To look at Threat Modelling in more detail, visit the Microsoft Secure Development Life-cycle (SDL) website which goes in to the technique in more detail. The approach I have shown here is more suited to development teams where there is no or only a limited security program in place.

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

ISSS Security Lunch - October 2010 - Review

Update 10/10/2010:  ISSS sent on a link to the presentation slides which I have included in the Links section at the bottom.
 
I attended the  Information Security Society Switzerland (ISSS) Security Lunch in Zürich on October 6, 2010. It was a civilised affair consisting of a sit down lunch, with a security presentation given between the first and main courses. About 20 people were present. I didn't know that ISSS existed until a few weeks ago.

The president of the ISSS, Thomas Dübendorfer gave a brief introduction to the speaker, Prof. Dr. Hartmut Pohl. Prof. Pohl is the CEO of softScheck which is a spin-off from the Hochschule Bonn-Rhein-Sieg  in Germany. Peter Sakal was also there to answer questions.

In his talk, Prof. Pohl gave an overview of their Secure Development Life Cycle (SDLC) which is called Rapid in-Depth Analysis (RiDA). The approach is similar to the Microsoft Secure Development Lifecycle (SDL). This is perhaps not surprising, since Microsoft is one of their partners.  RiDA places great emphasis on Threat Modelling, Fuzzing and Static Analysis. An important goal is to identify vulnerabilities before the project is actually launched. To achieve this, RiDA employs best-of-breed fuzzing tools to get the optimum results.  Code coverage is a significant driver. In their testing, softScheck aims to cover between 75% and 85% of the actual codebase.

Prof. Pohl provided statistics which show, that  RiDA identifies on average 50 critical vulnerabilities per application tested.

RiDA is a sound approach, as it provides a formalised SDLC methodology. But I can imagine that it is not cheap as, for example, the fuzzing tools require a lot of manual interaction. However, Prof Pohl argued that it is still a lot more cost effective to identify the vulnerabilities during the development phase than to wait until they are found in the wild.

As an aside, I wonder if that is always the case - especially in the web environment. A few weeks ago, a Cross Site Scripting (XSS) vulnerability was discovered in Twitter. While this was no doubt a bit embarrassing for Twitter, and perhaps did some reputational damage, they did have it fixed in a day or two. So it didn't cost too much and the issue itself will be quickly forgotten - except by us information security people.

Rapid in-depth Analysis is a contender in the drive to minimize security bugs, but you will probably need deep pockets to derive all the benefits. This implies serious commitment to security from company management.



Links:

• Presentation Slides (PDF)
• softScheck (German)
• Information Security Society Switzerland (ISSS) (German)
• Microsoft SDL
• XSS and Twitter

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

OWASP London Chapter Meeting October 2010 - Review

Last Friday night (October 1st 2010), I attended the OWASP chapter meeting in London. There were about 40 people present. A show of hands indicated that the majority of these were developers. It was held in the offices of Barclays Capital in Canary Wharf, so thanks to them for hosting the event.

How I Met Your Girlfriend - Samy Kamkar

Samy Kamkar was the first speaker on the agenda. Samy is well known because of the MySpace worm with which he was associated a number of years ago. He's kept a low profile since because, how to put this diplomatically, he was otherwise occupied.

However, he is now back in action and in the middle of his European tour. His talk was entitled How I Met Your Girlfriend. It was a highly entertaining talk, where his goal was to get the girl. The girl, in this case, being the girlfriend of a colleague. I think it was fictitious, although he was never quite clear on this point!

The talk covered a wide range of topics, from how to deconstruct a PHP session ID, to extracting the MAC address from a router, through to using Google location services to locate a physical address. I won't go into the details here. You should go to one his talks if you get a chance.

The talk was entertaining and informative, but ultimately slightly depressing. Depressing, not because of Samy, but because of the conclusion: the types of attacks he was demonstrating put yet another nail in the coffin of any illusions that we might have had about privacy. It's with O'Leary in the grave ¹. The discussion afterwards centred mostly on this privacy issue.

His European tour continues for the next few weeks. You can find more details on his website samy.pl.

Padding Oracle attacks (and ASP.NET 0-day) - Justin Clarke

In the second half of the meeting, Justin Clarke talked about the Padding Oracle vulnerability and gave a demonstration of his company's PadBuster tool.

Justin is OWASP's man in London.

For those of you who don't know, the Padding Oracle attack has been all the rage in the last few weeks. The attack targets weaknesses in the implementation of AES used in Microsoft asp.net, although it is not only Microsoft technology that is vulnerable. Last week Microsoft issued an out of sequence security patch. Everyone should apply this patch, even though Microsoft classified it only as being important and not critical.

Anyway, back to the talk. Justin gave a short overview of what the attack is about and how it works. It essentially targets the padding mechanism that is used to encrypt data (such as the viewstate) sent back by the application to the browser.

In the second half of his talk, Justin gave a live demonstration of the Gotham Digital Science PadBuster tool which is designed to automate the attack. The tool took a certain amount of tender love and care to get it to work - but work it did. It returned the contents of the web.config file from the sample asp.net application.

If you are involved in web application development, the main lesson to be taken from this, is that you should keep an eye out for any newly discovered vulnerabilities in the software components that you rely on. And then to make sure that you apply any relevant workarounds or patches that are issued.

Again, this was an enjoyable and informative talk with the added tension of the live demo. You can download a copy of PadBuster from here


With the business of the evening concluded, the chairman called a halt to proceedings. We adjourned to the local public house, where we told each other lies.

¹ William Butler Yeats: September 1913

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