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

A CEO with a Problem

Dear CEO,

Last night you went to bed content in the knowledge that your company was in good shape and that you were making big bucks. But, things have a habit of moving quickly. It's now 5 AM. You somehow find yourself booked to go on the major TV networks between 7 and 8 AM. You have to explain how somebody broke into your corporate database and stole the details of around one million customers. The hackers used something called SQL (pronounced 'sequel' by the way) injection. This story broke while you were in dreamland.

What do you do? All around, people are losing their heads, but not you. That is why you are CEO and the others aren't. You are determined to grasp victory from the jaws of defeat. You see an opportunity. Whether you like it or not, you're going to get airtime across these networks. You have, as ex-British prime minister Margaret Thatcher once put it, the oxygen of free publicity. Make the most of it. There are only two hours to prepare. Don't forget that tomorrow this will be yesterday's news, and the opportunity will be history. 

First step is to get the lawyers on the phone. Make sure that you don't incriminate yourself or the company. Always run the plans by the legal people. Next, contact your IT department. Don't forget these are the idiots who caused the problem in the first place - and don't let them forget it either. They should ensure that there is enough capacity in place to handle the extra visitors who will go to your website as a result of this incident. Get your marketing department to come up with great deals and to publish them on the website as soon as possible. When curious people visit the website during the day, hopefully the offers they see there will encourage them to stay as new customers. A cynical move maybe, but all is fair in love and…...

Plan what you want to say during the interviews. Here are some ideas:

• Be contrite but confident.
• Apologise to your customers for any inconvenience.
• Reassure them that the company will do everything possible to protect against any loss.
• Announce that you will facilitate access to credit monitoring programs.
• Emphasise the exceptional nature of this event by making the following kinds of statements: 'first indications are, this was an extremely sophisticated attack'
• Stress that the company already has robust information security practices in place, but you will be revisiting them.
• Say that you already have got external experts in to investigate the incident and that you will look to implement whatever recommendations these experts make.
• State that you will vigorously pursue the perpetrator responsible for this incident.

And now comes the opportunity: As this is a breaking story, emphasise that you will be posting updates to the website on a regular basis. Customers should visit to get the latest information. Make sure to mention the company's URL as many times as possible. This is the chance to advertise your wares both to existing customers and to potential new customers. Obviously, you can't say this explicitly in the interviews. But the visitors who came to watch the car-crash will hopefully remain as customers - enticed by the promotions that your marketing department create this morning. You have two hours to set all this in motion. Remember to get approval for the plans from the lawyers. Finally, use the last half-hour to run through some mock interviews.

Best of luck!

SIX MONTHS LATER:

OK, so things didn't work out. You are now the ex-CEO. But it did come with a useful golden handshake. You can now concentrate on the golfing handicap. 

OR:

Things worked out really well. After a brief hiccup, you increased your sales, and as a result of all the free publicity you received, you now have 10% more customers. Granted, you had to put aside some costs in the current accounting period, but they are manageable.  Ironically, you are now recognized as a world expert on crisis management!

The final item is to contact me, so I can tell you where to send the check!

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

OWASP Related Links for Developers

These are a few useful links for developers relating to popular development environments. 

OWASP Top 10 for .NET developers
  http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-1.html

The OWASP Top Ten and ESAPI (J2EE)
  http://www.jtmelton.com/2009/01/03/the-owasp-top-ten-and-esapi/

Using the OWASP PHP ESAPI
  http://jackwillk.blogspot.com/2010/06/using-owasp-php-esapi-part-1.html

Python Security
  http://www.pythonsecurity.org/

Don't forget all the resources on the OWASP website.

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

Audit Trail Basics

Updated: May 4th 2012 to add reference to OWASP Logging Cheat Sheet

Updated: August 26th 2010 to add reference to The European Payment Council document

Anybody who has looked at the Payment Card Industry Data Security Standard (PCI)  will know that audit activities are an important requirement. An audit trail will maintain a record of significant events, such as logon, logoff, password changes etc. From an information security perspective an audit trail is an important control as it can be used to help monitor what is happening - and to notice if anything unusual is taking place. In addition it should be able to help recreate what happened in the event of an investigation. Most web applications do not have a proper audit trail. There might be various log files. But it can be difficult to use these in helping to recreate what happened.

However, if the audit requirements are considered at the start of a project, it is easy to build in the appropriate infrastructure to support it. At its most basic, it is a simple API that can be called from anywhere within the application. The Audit API should include the userID, type of event (e.g. logon, logoff), success or failure, timestamp, description.  Then call the API whenever a significant event occurs - such as logon, logoff. The audit API can then write the event to a permanent store. This could be a database table, a Syslog Server or similar. With the basic infrastucture in place, there are a number of other considerations. A mechanism is needed to view the audit trail. Another question is how long the audit trail should be retained for.

Requirement 10 of PCI goes into much more detail as to what is expected if you are processing payment cards. For example, the audit trail should be tamper-proof. This becomes important when the audit trail is used during formal investigations.

Basic Steps
Here are the basic steps you should think about at the start of the application.

1. Define an audit API called something like WriteAuditEvent. The API should take at least the following parameters; userID, eventType (logon, logoff etc.),success or failure flag, description. Make sure that the audit trail does not contain sensitive information - especially passwords.
2. Define the initial list of audit event types. These should include all significant user lifecycle actions, such as logon, logoff, change password etc. More events will depend on the functionality of your application.
3. Call the WriteAuditEvent from the application when the events occur.
4. WriteAuditEvent should write the details (including timestamp) to an audit store. This could be a database table, file, Windows event log, Syslog Server etc. Ideally this store should be tamper proof.
5. Develop a mechanism for querying the audit trail. This should be fairly flexible to allow you to focus on certain events or users.
6. Decide how long the audit log should be retained for.

There's a lot more that could be written about audit trails. However those are some basic steps. It is easy to build in simple audit trail functionality if you think about it at the start of your development.

Some Links:

• You can download the PCI Standard from here here (PDF) 
• How to Do Application Logging Right talks about some technical aspects.
• Have a look at the OWASP API and AppSensor 
• In June 2010, the European Payment Council published THE USE OF AUDIT TRAILS IN SECURITY SYSTEMS: GUIDELINES FOR EUROPEAN BANKS
• OWASP Logging Cheat Sheet 

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

Forgotten Password Mechanisms....again

In  a previous  blog entry I gave my 2 cents worth on what to think about when handling the "Forgotten Password" mechanism in online applications.

I just came across Password Reset Survey  which does a short review of how the password reset is handled on a number of major sites*. It's worth reading, but here is the conclusion:

"There isn't a clear conclusion to draw here - sites do things differently, and in some cases have what seem to be pretty easily breakable password reset mechanisms. I'd imagine that all of these mechanisms work well enough - the cost of breakins is less than the cost of making things more secure and difficult for users. But I'd encourage people to think of ways that the password reset process could be made more secure and usable so that sites could rally around a better mechanism."

I have also mentioned the following academic paper before:

•  The password thicket: technical and market failures in human authentication on the web

When developing your online application, you need to think about how you are going to handle the forgotten password mechanism.

*The sites reviewed are:
Google, Yahoo, Microsoft (Hotmail, Live etc), Apple, Facebook, Twitter, MySpace, LinkedIn, Amazon, Ebay, Craigslist, Paypal, Wikipedia

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