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