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: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

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: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Switzerland, Hotel Check in and the Police

An interesting item on Swiss National Radio DRS1 (German) this morning. In certain cantons, when you check-in to stay in a hotel, your details go straight to the police electronically. The police will then check to see if the hotel guest is a person of interest.

The Data Protection Officer for Canton Zurich is not happy with this situation and is looking to get it changed. In the meantime, he suggests submitting as  little information as possible on checking in to the hotel. The other cantons mentioned are Lucerne and Basel Stadt. 

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

BBC Article on CEOP Website Security

There is an article on the BBC about a security vulnerability found on the Child Exploitation and Online Protection Centre (CEOP) website. According to the BBC:

"A member of the public found a form on the Child Exploitation and Online Protection Centre's website - to report alleged offenders - was unencrypted.
Security experts have described the breach of data as a serious error which could have put children at risk.

...

There will now be a full investigation by the Information Commissioner's Office.

...

The unencrypted pages meant personal details entered on the site could have been visible to anyone with a sinister motive."

So it looks like  the non-use of SSL on a website is a serious error which warrants a full invesitigation by the ICO.  Granted the CEOP processes sensitive information.


What does all this mean? What about the gazillion other websites that children use and which don't force the use of SSL? Answers on a postcard......

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

OWASP Zürich Meeting Tuesday April 12th - I am Speaking

I am speaking at the OWASP Zürich Meeting on Tuesday April 12th at 17:00. It looks like it will be held in the refined surroundings of the Rheinfelder Bierhalle in Niederdorf.

The title of the talk is not really defined - but the Security Requirements Quick Reference will do for now .... or maybe the Security Requirements Cheat Sheet

I intend covering the Security Requirements (Section 2) of my SDLC Quick Reference.  Basically how do you go about specifying the security requirements that your web application should meet. Topics will include data classification, data flow diagrams, threat analysis, etc.. The talk will use a simple ficticious website as a basis.

So if you are interested in how you go about gathering security requirements for your application please come along.

More details on the  OWASP Switzerland mailing list.

PS: .....And if you can't attend the meeting do have a look at the  SDLC Quick Reference on this blog

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

Winston Churchill on Passwords

Winston Churchill quote on passwords:

 "It has been said that the password is the worst form of authentication except for all the others that have been tried."

 OK. He didn't say that (as far as I know). I paraphrased him slightly. Here is the alleged original quote:

"It has been said that democracy is the worst form of government except all the others that have been tried."

http://www.quotationspage.com/quote/364.html

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

Tuesday Top Tip - Penetration Testing

Most companies use application penetration testing towards the end of the development life cycle in order to identify security vulnerabilities. This can be a problem - especially if you had not thought about security earlier in the development process.

What do you do if the pen test throws up major security issues?

If it's late in the development cycle, then these issues will be expensive to address. So you are more inclined to ignore them. That could leave you vulnerable.

Have you been in a position where a serious SQL injection vulnerability has been discovered two days before product launch? What to do? You know it would have been fairly simple to address if it had been discovered a lot earlier - but now it's not so simple.

So here are some Tuesday Top Tips:

1. You should think of application pen testing as a way to confirm that all your planned security measures have been implemented properly during the earlier development phases.
2. Try to do some pen testing as early as possible in the development. If you discover issues, they should be less expensive to address - and you can integrate the lessons learned into the rest of the development.

All this assumes that you have integrated security into the development lifecycle.

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