Bill Buchanan - Let's Talk About Spreadsheets

I remember attending a talk many years ago, and the presenter said, "I've got this amazing tool called Lotus 123", and he gave a practical demo of doing some calculations. People in the audience were stunned by the simplicity of its operation. It was the birth of the thing that drives many businesses … spreadsheets. They are just so simple to use, and we all love them. And so, in the PSNI (Police Service of Northern Ireland) data breach, it is a simple Excel spreadsheet that is being pin-pointed as the carrier of highly-sensitive information.

Overall, in the breach, there were four major failings:

1. A lack of training and awareness from those handling the FoI request.
2. A lack of checking and sign-off within the process.
3. Documents should be marked with the security classification, and access rights defined properly to highly confidential documents.
4. The use of spreadsheets to store sensitive data.

I hope that the first two are quite obvious in mitigating … send staff on cybersecurity courses, and improve your sign-off procedures. Now, let's turn on the mighty Microsoft Excel.

So, what's wrong with spreadsheets?

Well, they are NOT DATABASES and should not be used as a database. I've done quite a few code reviews and am always shocked by the number of back-end databases that use Microsoft Excel. Basically, Excel is a basic computing engine that is optimized for small problems and not for those that a database can cope with.

But, the main weakness is that they have virtually no inbuilt security and should not be used for sensitive data. Unfortunately, Microsoft has never really properly integrated security into Excel, and even encrypted documents are flawed in their operation.

The cyber-aware world has moved on from spreadsheets, and in many organisations, we see SAS (Software as a Service), which restricts access to data. Only those with the rights to access key elements of the data can get access to it. HR systems, too, are carefully guarded in cloud-based systems. In fact, moving your data into the public cloud really gives you an excellent viewpoint on how to protect sensitive data. I've seen some excellent data protection teams operating in banks, and much of their work is driven by automated software.

I appreciate that data sometimes needs to be exported into a spreadsheet, but if it does, it should be encrypted in its form and not rely on the operating system to do this.

Perhaps law enforcement — in places — is a decade behind the finance industry in setting up SOCs (Security Operations Centres), and where a well-run security infrastructure would be continually scanning for sensitive documents. Data protecting procedures have been implemented in many finance companies for years, and where scanners pick up documents that are stored in places they shouldn't be.

Network scanners, too, can pin-point sensitive documents within the infrastructure, and also when sent outside the network. Any document that leaves an organisation such as the police should, at least, be triaged, no matter if it is for email or Web. The detection of telephone numbers, personal names and addresses in a document is fairly trival with the usage of regular expressions. An alert should have gone up with the loading of a file with so many personal details.

Conclusions

Policing needs to learn from this data breach. They need to increase awareness and implement training, along with better sign-off procedures. But, basically, the need to catch up with the rest of the world and implement proper safeguards on sensitive information. The days of marking a document as "confidential" are gone — we need better data handling, and spreadsheets are typically not part of this for highly sensitive information.

I believe that the police and other government agencies can learn a great deal from the finance industry on cybersecurity practices. They are the most attacked sector, but have one of the lowest amounts of data breaches.