Senior officials now in frame for HMRC data fiasco Senior officials were involved in the decision to post the UK's child benefit database on unencrypted CDs, it emerged overnight. Sir John Bourn, head of the National Audit Office, said decisions were made at a higher level and that the NAO asked for the data be "desensitised" but this was rejected on grounds of expense. Her …
My expatriate brother in France turned 65 a couple of years ago. So he told the DHSS at Newcastle his current address for the first time in years, to get his pension.
His comment on the current fiasco: "It was notable that I received the El Gordo scam when ONLY the DHSS had my new address."
By accident or design these systems will leak data. This time the sheer scale of the leak makes it difficult to cover up, but steady leakage has its dangers too.
I don't think it would be as easy as a "filter" as some people have suggested. If you are doing an audit, you might want to see correlations in the data, such as how many people with the same name in the same house claimed more than x.
To do that you would have to change everyone's names, but not randomly, and have to be sure you ended up with the same statistics (i.e. don't change all Smiths and Joness to Williams). And the same with NI numbers, and addresses, and how to you make the postcodes anonymous and still useful in a geographical search, etc.
Sure there is a sliding scale on how much work you can do on this, but to do it right (and I can imagine the civil service being a do it completely right or ignore it place) would be a small project in and of itself.
All of this would mean that you can pass it onto the NAO and not worry about the security clearance for their DBA. (We face similar problems when sending copied of our live system to the vendor when trying to debug problems.)
Not encrypting - criminal. Saying making it "desensitised" has a cost - completely true.
Ill second that, Ive seen the same procedure in use with gov restricted cd's. Only we were told when we queried it that we had to use two envelopes for restricted items, and the inner envelope was to be addressed to ourselves, so in the event of a breach of the outer, hopefully they returned it to the address on the inner. We used to encrypt the contents against policy and email the pass to the recipient (ie by a independent means), but only because we cared slightly more about our reputation than the usual EDS mob.
Of course what would happen in practice is that anything that caused the outer to get ruptured would do the same to the inner envelope.
Government take on the chocolate fireguard if you ask me...
MR said "...but the Revenue refused as it would be too much work for their IT support run by......EDS!"
You're wrong dude - the story coming out is that it was supposedly *too expensive* for HMRC to - as Nick Brice points out - do a task that was outside of the agreed contract. So by trying to do it on the cheap, it's now costing them more! At least the HMRC head guy had the cojones to jump ship.
Why is EDS involved when they're supposed to be with Cap Gemini? Or are HMRC just too useless to grasp the concept of totally replacing one supplier with another.
Interesting office comment - anyone pick up on how fast the civil service unions managed to spin this to their own ends, almost if they knew it was going to happen? Now I find that very suspicious given that my experience of civil service unions (I used to be in one!) is that most of them couldn't find their a*s with a map and a big sign pointing at it.
Not that I'm suggesting for 1microsecond that they arranged it, but it's very convenient timing for them.
I feel sorry for the poor staff stuck "in the trenches" receiving abuse day-on-day. Us members of the public are not the only victims here, (although hopefully the two disks will turn up - [temporarily] lost in the post)
Think what you like, but the points made about 'just' executing a query are still valid.
Even if you have to fire up Microfocus COBOL workbench to do it, the principle still holds.
You obviously don't have much exposure to COBOL, a language which was designed to make writing and executing just such queries easy *. A system I worked on three years ago on ICL minis (yes, original ones at that) and which was largely written in COBOL sometime around 1976, was happily able to export a selection of fields to a CSV file for transfer to more modern kit.
In fairness COBOL programs often take a while to write because you need some downtime to recover from the psychosis inducing whitespace and indent rules and the enforced boilerplate. But the principle is very much the same.
The only question is why doing this should incur unacceptable delay and/or cost. Most likely because this counts as additional work under the outsourcing contract, the terms of which (esp in government departments) are so nit picking as to induce hysterics in all but the most fearsome contract experts, and are in fact designed to exploit just such situations.
This is a totally separate issue from the technology involved, and part of the "systemic failure" that Darling et al are so fiercely denying.
*Although weather that design goal was met is still a subject for some often strenuous debate, and I can easily imagine several COBOL coders have just spit coffee through their noses.
No - we just build a large ship - a "B" ark if you please*. Load it up with all the politicians, throw in all the PHBs, senior management teams, outsource account managers, client executives and third party consultants and every other golgafrinchan we can find and set it going off round in circles round the Atlantic.
We could even leave instructions on how to turn the autopilot off, set up lots of hidden cameras and have ourselves a nice reality TV program. We could have minutes of fun watching the useless sods form committees and steering groups (sic), project teams, publish newsletters, set up war rooms etc whilst they try to decide what to call the project to find someone to open the instruction manual.
In the meantime we would then get on with the job of delivering a proper service to who-ever our particular bunch of customers are.
* to Douglas Adams, thank you. Remembering that those in charge are just a load of useless bloody loonies is sometimes the only thing that gets me through the day.
On the one hand, take this with a pinch of salt because it's second-hand info.
On the other, like many governments and security forces around the world, HMRC do (as far as I can tell from some Googling) use Lotus Notes/Domino. Because out of the box it's roughly 1000 times more secure than anything MS have ever produced - ** when the database is on a server ***.
I'm told (as I say, second-hand, mate of a mate who works at HMRC) that the disks had two Notes databases on them.
Now, if you encrypt a Notes database when you replicate it locally and then send on the ID file that was used, or generate one-off encryption keys and send them on to be imported into the recipient's ID file then you have one damn secure database. Current version supports 2048-bit keys.
If you set "enforced ACL (access control list)" then you have something that looks secure but can be opened with a little effort by anyone with a Lotus certification.
If you don't do either then your last best hope is that the crims in posession of the disks don't know what a .nsf file extension is and/or don't know where to get a copy of Notes from!
Take this as I do - To Be Confirmed - but adds a little interest to the mix.
Speculate no more:
the BBC have published some of the correspondence and emails:
http://www.bbc.co.uk/blogs/nickrobinson/Informationrelatingtochildbenefitdata.pdf
It refers to a previous request which was sent in 100 zipped files on 2 CDs, and to send the password(s) in a separate email.
At this point you hope they used winzip v9 or later (with AES, or 7zip) and non-short password(s). Winzip v9 gives a max effective key length of 160 bits whether 128,192 or 256 bit AES key length is used (uses HMAC-SHA1, 1000 iterations, in a key derivation function -see RFC2898). Crack programs available will struggle with anything more than short password when faced with a zip encrypted using AES.
Unfortunately, it's more likely that Windows XP own built in zip was used which I think just uses the old (non AES, more easily cracked) Zip 2.0 compatible password protection.
It is just as likely that he was downloading a file generated by some pre-existing batch process. As child benefit has been around for over 30 years it is quite likely that there was already a job set up to extract this sort of information from the system. While it is easy for IT professionals to think of numerous ways that the data could have been cleansed after the download it is important to remember that the individual in question was probably a lowly qualified administrative officer who was probably following a set of written instructions parrot fashion. His breach of the HMRC procedures was probably not that he was acting outside his remit by downloading the data and sending it out unencrypted but that he used the internal post rather than registered mail as the mechanism. As there were postal strikes around the time that the event occurred he may even have been give verbal instructions by his manager to use a non standard route ( note to all civil servants advise your supervisor in writing every time you depart from set practise so he/she can not deny the fact later). The fact that this young and probably lowly paid individual ( say £13,000 p.a) is being scapegoated by politicians and the senior managers in HMRC for what is really the failure of a poorly designed and implemented IT process just goes to show how low some of the top people in government are prepared to stoop nowdays. To describe the official round of blamestorming and buck passing as pathetic does not really start to give full expression to my contempt for these people.
"We used to encrypt the contents against policy and email the pass to the recipient (ie by a independent means), but only because we cared slightly more about our reputation than the usual EDS mob."
Actually - as an EDSer (although nothing to do with the DII or Govt businesses) I'd just correct this. EDS' policy is pretty damn clear on what you're supposed to do with this sensitivity level of data. At the minimum it's to be "safeguarded" (dumb US speak for encrypted I guess) and "delivery to the it's intended recipient only must be ensured" (proof of delivery and pack tracking). I've heard of folks encrypting a file, and then doing again (with different pass phrases obviously), then phoning one passphrase to the destination person, and only giving them the other when they confirm that they got the file. Think that's a bit anal myself. :)
So if it had been one of my colleagues responsible, then the mandated punishments are disciplinary hearing, sacking and probably a spell in court.
But, and I realise that there's folks at El Reg who'll either dispute this, on this occasion the fault lies 100% with HMRC, so please don't try laying the blame at EDS' door. :-P
Still no idea...
Microfocus Cobol - on a mainframe?
I'm talking systems that are 20+ years old, on big (clue "VME") mainframe boxes, with all the controls and constraints that brings - develop, test, sign-off, code control, PTE test, sign-off, schedule, run... easy to charge a few man-days for even a simple scan in that sort of environment.
Never worked on the system in question, but I have worked on similar, and know how it is - all too well!
Even if it's an antediluvian mainframe system, running off an extract dataset with just the fields you want should take a decent techie oh, all of five minutes.
No procedures to follow, no source code versioning, no compile even, if you're lucky, and certainly no testing required, just bash off a quick little number in SAS, or Easytrieve or whatever you have to hand, and bish bash bosh, loads 'a' data wiv the dodgy bits left aaht.
There are different ways of treating name & address data to avoid DPA issues, by the way.
The obvious way is to encrypt the stuff to death.
The less obvious way is to use a commercial software package that obfuscates specific fields with gobbledegook; point it at the names and it'll "intelligently" change them so it's no longer possible to identify the people involved, but to a human eye they are still obviously names of some sort. Point it at the addresses, and it'll do a similar job.
In this case, it seems the names needed to remain unchanged, but the bank details could have been discombobulated by software. Of course, setting up a run of this sort of software is less than trivial if you want to do a good job: I wonder if this is what was being quoted as "too expensive"?
Within the pdf the email dated/timed 13 March 2007 13:11 seems a bit strange - "I hope you make sense to you than us however".
But what is the URAC mentioned in that email? In context it appears to be record/field layout/descriptor but I've never seen that term before.
BTW When NAO state the HMRC Process Owner "was a copy recipient of an email", please note that they do not state he was ONLY CC'd on one email in the entire email exchange.
The last statement limits the Process Owner's involvement, but the first leaves involvement undefined while implying a limit. (I've read a lot of Civil Service reports.)
According to the BBC 6 more CDs are missing. These contain audio files of customer complaints. It seems that they were shipped by TNT but never arrived.
TNT apparently said "it was impossible to say whether the CDs had ever entered TNT's system."
Err Excuse me - are TNT a courier service or are they a bunch of cowboys. How can a courier company get into a situation where they cannot say if they've ever actually picked something up. Sounds like they are as useless as the person who decided to use them to ship confidential data. Remind me never to use them if they are so clueless
Maybe all these "lost" CDs are actually just sitting on a shelf somewhere waiting to be picked up?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
