Thursday 26 May 2011

ICO Website and Cookies Law - Strange

The new cookies law comes into force in the UK today, although the ICO (Information Commissioner's Office) is allowing one year to comply with the new rules. The purpose is to ensure that:
  • "businesses and organisations running websites in the UK need to get consent from visitors to their websites in order to store cookies on users’ computers. "
How the ICO does it 
The  ICO on its website shows how it could be done - and it's strange. If you visit the website you are shown a fairly ugly header at the top:

It gives you an option to say "I accept cookies from this site". So the first thing that strikes you is why is there is no option to say:
  • "I DO NOT accept cookies from this site."
The ICO site uses Google Analytics to track visitors. You can go to the ICO Privacy Notice page and follow a link which allows you to download an AddOn from Google which might allow you to disable the cookies....but I doubt if many users will go to the effort of doing that.

Fiddler shows me that if I don't click on the "I accept cookeis from this site" header and just leave it there, no traffic goes to Google Analytics

So in effect, if you don't want to accept ICO cookies, the best thing is leave the header on top of the screen and not to click it. Just ignore it.

Firefox - Do Not Track
Do Not Track - DNT
In addition I use Firefox 4 and I have set the option
  • Tell web sites I do not want to be tracked
 This is under "Tools!Options!Advanced!General". This sends a DNT request in the Request Header. So ideally the ICO should honour that and should never ask me in the first place whether I want to accept cookies.

The way the ICO website implements the new cookie law is not elegant.

Social: DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Friday 20 May 2011

My OWASP AppSec Europe 2011 talk

I'm giving a talk at the OWASP AppSec Europe talk in Trinity College, Dublin, Ireland on Friday June 10th at 11:10. It's part of the Prevent track.

The talk is aimed at developers (or builders as OWASP calls them). At the start of a development project you should think a bit about security. In the presentation I will go down through a simple structured list of security  tasks that you should do in order to gather the security requirements that the project should implement.

If you spend a few hours thinking about security early on, you could save yourself a whole lot of problems later on. A workshop with the relevant people is a suitable format for this. The list of tasks which the presentation outlines can form the basis for this security workshop.  

In fact, you can use the list of tasks as the agenda for the workshop.

A fictitious website which processes personal information (as defined by EU Data Protection Legislation) will be used as an example.

Even QEII likes the list
The list will include the following:
  • Data Classification
  • Simple Threat Analysis
  • Data Flow Diagram
  • User LifeCycle/Authentication etc.
  • Authorisation
  • Segregation of Duties
  • Audit Trail
  • Data Retention
  • Availability/Resilience
  • Other Compliance Issues

If you spend a few hours at the start of a project going through this list, you will have a good idea of your security requirements and what you need to do. It is much better than trying to do this at the end.

This is what I will try to get across in this talk. So if you are on the development side of the house and you are interested in a simple approach to specifying your security requirements then do come along to the talk.  It will be an XSS-free zone!

The security list is based on Section 2 of  the SDLC Quick Reference

Social: DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Monday 2 May 2011

ICO Data Protection Principles and Online Applications

Schedule 1 to the UK Data Protection Act lists 8 data protection principles. You can read more on the Information Commissioner's Office (ICO) website here. If you are developing an online application which processes personal information what are the implications?

This blog entry delves a bit deeper.

Privacy Notice

First, a short discussion about the "privacy notice". According to the ICO, this is the notice "that individuals are given when information about them is collected". Typically you will display it on your website.  The ICO has issued a Privacy Notices Code of Practice  "to help organisations draft clear privacy notices and to ensure they collect information about people fairly and transparently".

Having a proper "Privacy Notice" in place is the main step you can take in adhering to a number of the Data Protection Principles.  So one of your first tasks is to develop an appropriate Privacy Notice and then to adhere to it.

Data Protection Principles

The following sections lists the principles and the implications they may have for your online development.

Principle 1
Personal data shall be processed fairly and lawfully and, in particular, shall not be processed unless –

(a) at least one of the conditions in Schedule 2 is met, and

(b) in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met.

Implication: Have an appropriate Privacy Notice in place.
                                                                           *      *      *

Principle 2
Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes.

Implication: Have an appropriate Privacy Notice in place.
                                                                           *      *      *

Principle 3
Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.

Implication: Have an appropriate Privacy Notice in place.
                                                                           *      *      *

Principle 4
Personal data shall be accurate and, where necessary, kept up to date.

Implication: The application will need to be able to provide users with access to their personal information. The application should also have a mechanism to allow personal information to be updated. For example, if a user moves home, the application should have a facility in place which supports address updates. Either the user does this themselves directly by logging on, or a Customer Services Agent has the ability to do this on behalf of the customer.
                                                                           *      *      *

Principle 5

Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes.

Implication: This should be covered under a data retention policy. The application will need a manual delete function which removes a user's personal information. Either the user does this themselves directly by logging on, or a Customer Services Agent has the ability to do this on behalf of the customer.

The application may also need an automated delete mechanism which automatically erases customer information after a certain period of time or inactivity.

You need to be careful about this principle as it may conflict with other requirements which force you to maintain records for a certain minimum period of time. This could especially be the case with financial transactions.

Another tricky area is audit trails. How long should they be retained for?
                                                                           *      *      *

Principle 6
Personal data shall be processed in accordance with the rights of data subjects under this Act.

Implication: Have an appropriate Privacy Notice in place.
                                                                           *      *      *

Principle 7
Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

Implication:  This is where the main information security good practices come into play. These include topics such as authentication, authorisation, encryption, audit trail, OWASP Top 10 etc. The Security Requirements section of the SDLC Quick Reference is essentially aimed at trying to meet the requirements of this principle.
                                                                           *      *      *

Principle 8
Personal data shall not be transferred to a country or territory outside the European Economic Area unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data. 

Implication:  Before transferring personal data to a third country, you need to ensure that the third country has adequate levels of protection in place.  You need to be careful about using real personal information in development and test environments - especially if you outsource development to third parties.

Subject Access Request

One of the main rights which the UK Data Protection Act gives to individuals is the right of access to their personal information. A user can send a Subject Access Request  requiring you to provide them with a copy of the personal information that you hold about them.

Implication:  Your application should provide functionality which supports this requirement. When a Subject Access Request arrives, your application should have a function which can return all information for that user.

Social: DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot