The DOBlog

In the interests of a bit of balance, and prompted by some considered comment by Owen O’Connor on Simon’s post over on Tuppenceworth, I thought it might be worth focussing for a moment on what the IBTSB did right.

1. They had a plan that recognised data security as a key concern.
2. They specified contract terms to deal with how the data was to be handled. (these terms may have been breached by the data going on an unexpected tour of New York)
3. They made use of encryption to protect the data in transit (there is no guarantee however that the data was in an encrypted state at all times)
4. They notified promptly and put their hands up rather than ignoring the problem and hoping it would go away. That alone is to be commended.

So they planned relatively well and responded quickly when shit hit the fan. The big unknown in all of this is whether the data has been compromised. If we assume happy path, then the individual in an organisation which had a contractual obligation to protect the security of the data but took it home anyway kept the data encrypted on the laptop. This may indeed be the case. I

t could also be the case that this person didn’t appreciate the obligations owed and precautions required and, apart from removing the data from a controlled and securable environment, had decrypted the data to have a poke around at it. That is the crappy path.

Ultimately it is a roll of the dice as to which you put your trust in.

In previous posts I have asked why production data was being used for a test event and why it had not been anonymised or tweaked to reduce its ability to identify real individuals. In his comment over on Tuppenceworth, Owen O’Connor contends that

the data being examined was to do with the actual usage and operation of the IBTS system

If the data that was being examined was log files for database transactions then one might query (no pun intended) why personal identifying data was included. If it was unavoidable but to send sample records (perhaps for replication of transaction events?) then this might actually be in accordance with the IBTSB’s data protection policy. But if the specifics of names etc. were not required for the testing (ie if it was purely transactional processing that was being assesed and not, for example, the operation of parsing or matching algorithms) then they should have and could have been mangled to make them anonymous with out affecting the validity of any testing that was being done.

If a sound reason for using real data exists that is plausible and warranted the level of risk involved then (having conducted similar testing activities myself during my career) I’d be happy that the IBTSB had done pretty much everything they could reasonably have been asked to do to ensure security of the data. The only other option I would possibly have suggested would be remote access to data held on a server in Ireland which would have certainly meant that no data would have been on a laptop in New York (but latency on broadband connections etc. might have mitigated against accurate test results perhaps).

In the Dail, the IBTSB has come in for some stick for their sloppy handling. Owen O’Connor is correct however - the handling of the spin has been quite good and most of the risk planning was what would be expected. If anyone is guilty of sloppy handling it is the NYBC who acted in breach of their agreement (most likely) by letting the data out of the controlled environment of their offices.

So, to be clear, I feel for the project manager and team in the IBTSB who are in the middle of what is doubtless a difficult situation. But for the grace of god (and a sense of extreme paranoia in the planning stages of developer test events) go I. The response was correct. Get it out in the open and bring in the Data Protection commissioner as soon as possible. The planning was at least risk-aware. They learned from Nixon (it’s the cover up that gets you)

However, if there was not a compelling reason for real data about real people being used in the testing that could not have been addressed with either more time or mor money then I would still contend that the use of the production data was ill-advised and in breach of the IBTSB’s own policies.

One of the joys of having occasional bouts of insomnia is that you can spend hours in the dead of night pondering what might have happened in a particular scenario based on your experience and the experience of others.

For example, the IBTS has rushed to assure us that the data that was sent to New York was encrypted to 256bit-AES standard. To a non-technical person that sounds impressive. To a technical person, that sounds slightly impressive.

However, a file containing 171000+ records could be somewhat large, depending on how many fields of data it contained and whether that data contained long ‘free text’ fields etc. When data is extracted from database it is usually dumped to a text file format which has delimiters to identify the fields such as commas or tab characters or defined field widths etc.

When a file is particularly large, it is often compressed before being put on a disc for transfer - a bit like how we all try to compress our clothes in our suitcase when trying to get just one bag on Aer Lingus or Ryanair flights. One of the most common software tools used (in the microsoft windows environment) is called WinZip. It compresses files but can also encrypt the archive file so that a password is required to open it. When the file needs to be used, it can be extracted from the archive, so long as you have the password for the compressed file. .
So, it would not be entirely untrue for the IBTS to say that they had encrypted the data before sending it and it was in an encrypted state on the laptop if all they had done was compressed the file using Winzip and ticked the boxes to apply encryption. And as long as the password wasn’t something obvious or easily guessed (like “secret” or “passw0rd” or “bloodbank”) the data in the compressed file would be relatively secure behind the encryption.

However, for the data to be used for anything it would need to be uncompressed and would sit, naked and unsecure, on the laptop to be prodded and poked by the application developers as they went about their business. Where this to be the case then, much like the fabled emperor, the IBTS’s story has no clothes. Unencrypted data would have been on the laptop when it was stolen. Your unencrypted, non-anonymised data could have been on the laptop when it was stolen.

The other scenario is that the actual file itself was encrypted using appropriate software. There are many tools in the market to do this, some free, some not so free. In this scenario, the actual file is encrypted and is not necessarily compressed. To access the file one would need the appropriate ‘key’, either a password or a keycode saved to a memory stick or similar that would let the encryption software know you were the right person to open the file.

However, once you have the key you can unencrypt the file and save an unencrypted copy. If the file was being worked on for development purposes it is possible that an unencrypted copy might have been made. This may have happened contrary to policies and agreements because, sometimes, people try to take shortcuts to get to a goal and do silly things. In that scenario, personal data relating to Irish Blood donors could have wound up in an unencrypted state on a laptop that was stolen in New York.

[Update**] Having discussed this over the course of the morning with a knowledgable academic who used to run his own software development company, it seems pretty much inevitable that the data was actually in an unencrypted state on the laptop, unless there was an unusual level of diligence on the part of the New York Blood Clinic regarding the handling of data by developers when not in the office.

The programmer takes data home of an evening/weekend to work on some code without distractions or to beat a deadline. To use the file he/she would need to have unencrypted it (unless the software they were testing could access encrypted files… in which case does the development version have ‘hardened’ security itself?). If the file was unencrypted to be worked on at home, it is not beyond possiblity that the file was left unencrypted on the laptop at the time it was stolen.

All of which brings me back to a point I made yesterday….

Why was un-anonymised production data being used for a development/testing activity in contravention to the IBTS’s stated Data Protection policy, Privacy statement and Donor Charter and in breach of section 2 of the Data Protection Act?

If the data had been fake, the issue of encryption or non-encryption would not be an issue. Fake is fake, and while the theft would be embarrassing it would not have constituted a breach of the Data Protection Act. I notice from Tuppenceworth.ie that the IBTSB were not quick to respond to Simon’s innocent enquiry about why dummy data wasn’t used.