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

Data Classification and Security Requirements

At the start of a web development project you should think about the security requirements that your application needs to meet.  What legislation, industry standards etc. are relevant? One handy way to do this is to classify the type of data that the application will process. The classification can help you work out the security requirements. In addition, many information security standards such as the ISO 27001 family,recommends the use of data classification.

Here are a number of classifications which may be useful.

Public Data

This includes information that is published to a website and is available to the general public. Examples are general product or company information. The main security drivers here are probably corporate governance rules and general good web security practices (OWASP Top 10). Confidentiality is not really an issue as you want people to see it. However, the integrity is important. Malicious users should not change it.

Public data is usually either purely static or database driven.  For static html the main risk to be addressed is OWASP Top 10 - Security Misconfiguration (A6).  For a database driven website, the main risks are the standard injection and  validation issues OWASP Top 10 A1, A2 etc.. 

Personal Data

If your website processes names and addresses, then your application will need to comply with local Personal Data legislation. This is probably the most common type of classification. EU countries have implemented the European Data Directive (Directive 95/46/EC) into national legislation. The  Information Commissioner's Office is responsible in the UK. In Ireland it is managed by the Data Protection Commissioner).  Other EU countries will have corresponding bodies.

In the US state of Massachusetts the relevant law is  "201 CMR 17.00: STANDARDS FOR THE PROTECTION OF PERSONAL INFORMATION OF RESIDENTS OF THE COMMONWEALTH" which is in force since March 2010.

You should become familiar with the relevant data protection legislation in your jurisdiction.

Payment Cards

If you "store, process or transmit" payment card information your application will need to comply with the Payment Card Industry - Data Security Standard (PCSI DSS ). Requirement 6 is the main one for web application security, although many of the requirements apply.

Money

This is a broad category covering such applications as online banking etc. There are many security drivers here such as Federal Deposit Insurance Corporation  (e.g. on multiple factor authentication), the European Payments Council etc.

Intellectual Property

For intellectual property, the main security driver will be corporate governance rules and internal organisation standards.

Summary

Those are just some data classifications which you can use in determining what are the security requirements that your application needs to meet.  There are many more depending on the sector that you are in.

Your company or organisation may have internal standards or policies that your application will need to comply with.  In fact, this is the first item you should research. This applies especially to larger or multinational organisations.

To summarise, if you are starting out on a new web development project, one of the first things you should do is to classify the type of data that your application will be processing. The classification will help you identify the security requirements that your application will need to meet.

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

Is the mobile phone becoming the universal authentication device?

Update 13/10/2010 : It now looks like Facebook is going down the same route with   One Time Passwords It looks like the question I posed in my original post (below) has been answered!

Is the mobile phone becoming the universal authentication device?  Are the days of website authentication using passwords only, coming to an end?

In the last number of months Microsoft has introduced "single-use codes" for its Windows Live Sign-In.


More recently Google announced that is introducing two-step verification initially to its Google App Premier accounts and says that "in the coming months, Standard Edition and hundreds of millions of individual Google users will be able to enjoy this feature as well."

Both of the above companies are main-stream consumer websites with hundreds of millions of users. Even though they are taking different approaches, the mobile phone is the common factor. They are perhaps acknowledging that password based authentication is no longer sufficient.

By doing this, the companies are raising the "security bar". Is it possible that a corresponding "shift" will take place over the next few years in the thinking of general consumers? Users may expect to use their mobile phones for authentication and decide that password-only based websites are not secure enough.

More importantly, the authorities may come to a similar conclusion. When the Data Protection Act states that "appropriate security measures" must be taken, will that come to mean that passwords by themselves are no longer "appropriate"? 

On the consumer banking front, Credit Suisse is rolling out an SMS based system in place of its RSA SecureId device.

Will Facebook etc. go down the mobile phone route for authentication? Update13/10/2010. Facebook has

If you are developing web applications, you should keep an eye on this space. Otherwise you may be left behind.

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

OWASP ASVS "Level 0 - No Verification"

According to OWASP, the Application Security Verification Standard (ASVS)
   "can be used to establish a level of confidence in the security of Web applications."

ASVS is a great idea, eventhough my efforts to introduce it have been 100% unsuccessful. Any takers?

The standard defines four verification levels ranging from 1 to 4. Broadly speaking you can verify the security of your applications based on a specific level. For the least critical applications you might verify to level 1 - which is basically an automated scan. If it passes the scan, then the application is secure enough.

For the most critical applications you could verify to level 4. This includes manual testing, code reviews of all code (including external libraries).

Level 0 - No Verification
I think that there is an implied 5th level which is "Level 0 - No Verification". Basically we have no level of confidence in the security. Most current applications probably fall into this level. The applications have not been subject to any security verification. This does not mean that they are not secure. But since they have not been verified, we can have no confidence in the security so they fall into our imaginary ASVS Level 0.

This begs the question, should ASVS formally include "Level 0 - No Verification"? Probably not. No point really! Developers could claim that their applications have been verified to Level 0 - which defeats the purpose.

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

UK Information Commissioner (ICO) Enforcements and Website Hacks

Summary

I did a brief analysis of the enforcement notices that have been handed out by the UK Information Commissioner (ICO) to organisations found to be in breach of the Data Protection Act. The idea was to see how many incidents were a result of a website hack (SQL Injection, XSS etc.)  About 100 enforcements are listed on the  ICO website covering the period from January 2008 to August 2010.

I found that none of the breaches were the result of a website hack. No SQL injection, XSS, CSRF attacks etc. The vast majority were related to unencrypted USB sticks, CDs, laptops etc. which have been lost or stolen.

Details

The Information Commissioner's Office (ICO) is responsible for the enforcement of the Data Protection acts (as well as other legislation) in the UK.

The ICO Enforcements page contains a list of enforcement notices that they have undertaken against organisations found to have been in breach of Data Protection legislation. The notices generally contain a short description of the breach as well as the remedial action which the implicated organisation undertakes to implement.

What is of interest from a web application security perspective is an analysis of the security incidents to see how many were caused by a website vulnerability - basically whether a website had been hacked.

I did a brief (not-very-scientific) analysis of the enforcements which have been published on the ICO website and focussed on the description of the breach.There were slightly fewer than 100 enforcements between 16 January 2008 and 26 August 2010. 

I categorised the incidents as follows:

Unencrypted Media is where an incident occurred following the loss or theft of a device which contained personal information and was not encrypted. This could be a laptop, CD, USB memory stick, old hard drive etc. It also includes a number of cased where users sent out unencrypted emails to the wrong recipient. For example the Royal Wolverhampton Hospitals NHS Trust enforcement has the following description :

The report concerned an unencrypted CD, with no password protection, which contained scans of patient charts from the Intensive Care Unit of the data controller's Heart and Lung Unit, and was allegedly found at a bus stop near the data controller's premises and passed to the newspaper anonymously."

Loss of Paper Records covers incidents where paper records were involved. This could be where patient records were found in a waste skip etc.. An example is the NCL (Bahamas) Ltd  which suffered a theft where:

the printout contained names, addresses, dates of birth, National Insurance numbers, salary details and full bank account details for around 80 employees."

Website Hack includes situations where a website was hacked. We would expect to see OWASP Top 10 type vulnerabilities being exploited which resulted in a breach of personal data.

Others is a catch-all for other types of incidents described in the enforcements. This could be where the organisation processes personal data in an unfair manner. For example they collect too much data.

Results

Here are the results of the analysis of the approximately 100 enforcements:

Category	Approximate Number Incidents
Unencrypted Media	70
Loss of Paper Records	20
Others	4
Website Hacks	0

A number of points to note. None of the incidents resulted from a website hack. No SQL Injection. No XSS. No CSRF. The vast majority resulted from the loss of an unencrypted device - or similar.

Can we conclude that OWASP (in the UK at least) can pull down the shutters - a job well done?  Probably not. 

But if I were an information security manager trying to prioritise the following projects:

• Do something about web application security
• Do something about USB/laptop encryption

Guess which one would go in second place.

Notes:

The numbers are approximate because in some cases the incident will have two causes. In other cases, a single enforcement notice covers multiple incidents.

There is not yet a requirement to notify the authorities of a data breach. So the figures probably do not tell the whole story.

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