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.
- They had a plan that recognised data security as a key concern.
- 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)
- 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)
- 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.