« October 2007 | Main | December 2007 »
Security companies praise the Lord and HMRC
Any security company worth their salt has been bombarding companies looking at the situation vis-à-vis Her Majesty’s Revenue and Customs (HMRC) and wondering about their security procedures and technology.
In the Labs we’ve just set up a system from log data management and compliance vendor LogLogic, which looks tailor made to address problems like those currently putting HMRC in the spotlight. We have a LogLogic LX 2010 appliance which is collecting and collating log event data from our numerous systems. This then passes them on to an ST 3010 appliance which archives the logs and creates a searchable data archive, which should make it easy for system admins and even tech journalists to spot and alert on policy breaches. Like for instance, somebody copying a database and putting it un-encrypted onto a CD and ‘protecting’ said data with just a password.
I presume LogLogic marketing managers will be quietly confident that their systems might get an extra boost from the shenanighans currently plaguing public sector IT. We’ll put putting out a full review of the system, hopefully before Santa sets Rudolph out on his one year mission to disappoint your kids.
Child Benefit records kept in CSV format!!?
Speculation is growing that the estimated 7m Child Benefit records were contained in nothing more sophisticated than CSV (comma separated variable) files.
The known facts about the data: that it was not encrypted, had basic password protection, and its entire output fitted onto just two CDs (or was it DVD-Rs, there is a big capacity difference after all!?) all indicate that the data was exported into a word processing or spreadsheet file from another database.
Worse, the admission that the complete dataset, rather than just the NI records actually required by the NAO, was exported and copied because it would cost too much for the specific information contained in individual fields to be extracted from the original database, suggests that the data may be natively kept in an unstructured format within which it is difficult to run accurate searches.
To be fair, many companies still keep a lot of information in unstructured databases, just on a much smaller scale, and certainly not the names, addresses, dates of birth, NI numbers and bank details of up to 7m million people!
Whether this kind of shambolic, irresponsible database management policy is exclusive to the HMRC is hard to tell, but I'd like to stick up for another government department at least.
Many years ago I worked for the Home Office Immigration and Nationality Department (IND) where the records of non EU citizens residing in or visiting the country were kept in a fairly ancient, but huge mainframe database that at least had the benefit of being structured.
So, whenever some government minister or MP wanted to look clever by spouting out some relevant statistics in parliament to support whatever argument they were trying to promote or undermine (like how many Croats, Bosnians or Serbs were admitted on tourist visas during 1992 and never went home, for example - a fair few considering the war in Yugoslavia at the time) I was given the job of whipping up a quick 2G program that went into that vast information repository and came out with more or less exactly the results they wanted, without exporting any of the data contained in the fields I was not interested in.
The process wasn't especially quick and the programming language in use (some strange derivative of Cobol) was hardly intuitive, but old programs could be swiftly amended and compiled, then left running quietly in the background over a couple of hours whilst I did something else.
Even then, the actual results were provided very much on a need to know basis, even though they were not especially sensitive and were, in fact, published every three months.
At the time, I was naïve enough to think the entire civil service kept and searched on its records in a similar way – either I was wrong, or government IT in some respects has actually changed for the worse, rather than the better, over the past decade ...
HMRC child benefit database - is it a spreadsheet?
A bit ironic that the first major corporation to be nailed to the wall on a compliance issue in the UK, will be Her Majesty's Revenue and Customs. Well, they won't be 'nailed' will they – too embarrassing for the Government. Just an enquiry which will finally report years down the line, with the Government saying that the system has changed and there's new safeguards in
Let's forget about the security arrangements around the database for a minute and try and think what type of database is being used? Is it a proper database, with proper record fields or are there some flat text files in there which are used as pseudo-records. Is it the case that HMRC can't run proper queries against their database, i.e.
BEGIN
for all the data
get just the Name and NI number record fields;
write that data;
END.
OK they'd use a dedicated query language, but you get the idea. Plus, how come a 25 million unique record database can fit on 2CDs? If we give everybody 100 bytes of ascii, that's 2.5GB – a bit more than 2CDs. Compression? No doubt the inquiry will sort all this out and then we can move to that National ID Database secure in the knowledge that it couldn't possibly happen again.
Google's nice little earner
So, is Google making Ethernet switches as reported by Nyquist Capital analyst and blogger Andrew Schmitt? Well, Google has 'not commented', but they have enough servers in their myriad data centres that need fast interconnects, so if it did approach the usual network vendors for a quote, one suspects the price was not right.
Why couldn’t these vendors do what would give them a staggering deal with Google? Schmitt suggests that it was lack of low cost kit available on today’s market. That says it all, some switch vendors, and they know who they are, only allow their own optical transceivers to be used with their switches - by 'allow' probably means voided warranty and support. Makes a nice little earner, as Arthur Daley would no doubt say. Of course Google's size means they can say, "Thanks, but no thanks - we’ll roll our own."
Of course, it begs the question, would they knock out a few extra for the market? Could be an even nicer little earner, especially if you check out research firm Infonetic's latest figures on the 10 gigabit Ethernet enterprise and service provider market which show 300,000 ports shipped in 2006 to over three million by 2010.
Photo: BlackBerry Pearl 8120
This photo shows how small and neat RIM's latest BlackBerry device is. The Pearl 8120 adds 802.11b/g Wi-Fi capability to the basic Pearl handset design that was introduced last year, without increasing the size at all and adding just a couple of grams to the weight.
For workers that already use a BlackBerry, the SureType keyboard will probably count against switching. This puts two letters on each key and uses predictive algorithms to work out what you are trying to type. It works quite well, but slows you down sometimes and is probably not the best solution for those who need to send lots of emails.
However, if your company has a BlackBerry server and you don't necessarily need to respond instantly to every email sent to you, then the Pearl is definitely worth a look. Its size and weight are in line with many basic Nokia handsets, making it easier to carry than some earlier BlackBerry models.
The addition of Wi-Fi means that the Pearl can browse web sites much faster when in range of an access point, but has little real impact on the email service.
A full review of the BlackBerry Pearl 8120 will appear in a future issue of IT Week, and the device is available now in the UK from O2.
