Whenever I investigate a security problem within an organisation, the initial reaction is usually the same. If it's related to process and procedures, I will be told, "It's a one-off", or "It couldn't happen again, we were unlucky." If it's related to software, I hear something along the lines of, "Well, we'll just fix the bit that was wrong."
Not entirely dissimilar, in fact, to the reaction from the Prime Minister this week, and the suggestion that this whole sorry affair at HMRC was triggered by a junior member of staff not following well laid down procedures. A simple, honest mistake.
Sorry, Mr Brown, I just don't buy that story.
The loss in transit of 25 million confidential records by a government department is, frankly, catastrophic - and catastrophic failures don't "just happen". Look at any major man-made disaster, and you'll soon realise that it takes a chain of events - a series of errors of judgements, a failure of internal controls, poor planning, inadequate training and a host of other things that all need to come together at the same time to turn an honest mistake that gets spotted and corrected into something far more serious. Luck can play a part, but bad luck is not in itself a sufficient condition here.
At any point along the line, someone, anyone could have stopped these CDs from being prepared, let alone from leaving the building. Clearly, staff at all levels within HMRC need to access and process data as part of their job. Very few, however, should be able to compile such a huge data set without passing through some very serious security checks and overcoming a number of practical difficulties. At least that's what one would hope.
So let's look at some of the practicalities here. Retrieving 25 million confidential records isn't like opening "child_ben_2007.xls" in Excel on your PC. For a start, this is a very large data set that would probably tie several systems up for some time. Uncompressed, a single record could be at least 100 bytes long. Twenty-five million such records would be 2.5 gigabytes of data - not huge in modern computing terms, but still significant in terms of a database retrieval. The computer systems in use at HMRC are a mix of old and news systems, extremely complex in their interconnection and built and maintained by developers and programmers - not by junior clerks.
The BBC reported that a 23-year-old man has resigned over the disappearance of the two data CDs. However I find it hard to believe that an individual daft enough to pop confidential records in the post would alone possess the skills and the access rights to be able to export 2.Gb of confidential data and then compress and span that data across two CDs. Not, at least, without some help.
I can only draw one conclusion - that the HMRC's computer systems have been explicitly written to allow the export of such huge quantities of data. And why would they do that? Because the bulk export of confidential data is standard practice within HMRC, and probably every government department, local council, benefit office and job centre in the country.
Of course, there may be good reason for all of this. Whether just good housekeeping or the determination to catch up with benefit fraudsters and tax-credits cheats, the government needs its various departments to share data.
I for one will not be surprised if this turns out to be just the tip of the iceberg. I expect the ongoing investigations to yield much further embarrassment for the government. What about all the CDs that don't get lost, for example? Any fool can copy a CD and then pop it in the post - it's doubtful whether anyone would be any the wiser. And who else, specifically, has had uncontrolled access rights to our most personal data over the last few years?
The real fraud risk
Should this information have fallen into the wrong hands (and that would just be speculation at this stage), then it's very unlikely that it will be used just yet. It is believed that credit card details are stolen as many as five times before they are actually used. Criminals aren't stupid. They know what to spend and how to spend it to stay below the fraud protection radar and get the most out of your personal information.
The real risk is the ability to use your identity combined with bank details to obtain a line of credit. Perhaps ordering items in your name, where you don't find out until the bailiffs turn up. Or by paying for things through direct debit from your account.
Companies like Masterwatch Credit Check [1] and Experian offer regular credit reports and even on-line access to credit ratings. CIFAS [2], for example, offers protective registration through Equifax for a one-off fee.
I wonder if the government would consider covering the cost of these services - who knows, they may even get a discount if they request more than 20 million registrations in one go?
Where now for Data Protection?
The Office of the Information Commissioner has long been a joke within the security community. Even if you are a large organisation, the chances of being caught and then fined by the Information Commissioner are anything from virtually zero to non-existent.
When Nationwide was fined almost £1 million for losing a laptop containing 11 million unencrypted customer records last year, it was the FSA that imposed the fine, not the Information Commissioner. I suspect that all this is about to change, but wonder whether this will simply mean more red tape for small businesses, and very little change where the biggest problems lie.
Related articles
Gray Tuesday for HMRC: Chairman resigns over data breach [3]
HMRC data security lapses - the final straw [4]
Information security [5] - 10-part Expert Guide series
Focus on data protection [6]
Stewart Twynham
Bawden Quinn Associates Ltd [7]
Links:
[1] http://www.accountingweb.co.uk/products/creditcheck/index.html
[2] http://www.cifas.org.uk/default.asp?edit_id=565-85
[3] http://www.accountingweb.co.uk/cgi-bin/item.cgi?id=175968&d=1025&h=1023&f=1026&dateformat=%o %B %Y
[4] http://www.accountingweb.co.uk/item/175951/1032/1023/1026
[5] http://www.accountingweb.co.uk/cgi-bin/item.cgi?id=119708&d=1032&h=1023&f=1026&dateformat=%o %B %Y
[6] http://www.accountingweb.co.uk/cgi-bin/item.cgi?id=176223&d=1032&h=1023&f=1026&dateformat=%o %B %Y
[7] http://www.bawden-quinn.co.uk