Sophos Cloud Optix
In June 2015, someone connected to Plymouth University accidentally sent a spreadsheet containing the salaries, pensions and allowances of 245 senior staff to the wrong email address.
The error was reported to the UK’s Information Commissioner (ICO), and the file was said to have been deleted by the recipient. Until, that is, the same file turned up last week in the inbox of a local newspaper from an anonymous source.
The university’s solicitor told the newspaper:
It is clear from the face of this document that this information should not have been sent to you or any third party. We should be grateful if you would delete this information from your records immediately and confirm to us in writing when you have done so.
The file’s sudden reappearance draws attention to the security hole that allowed it to happen at all – the file doesn’t appear to have been encrypted.
On the assumption that the application used was Excel, the breach raises the interesting chestnut of whether using Office’s in-application encryption would have helped.
We say “chestnut” because Microsoft’s integrated document encryption, which allows a file to be protected with a password (not to be confused with document editing protection), has had a mixed press.
A basic problem is that encrypting a document stops other people from accessing it. The password can be shared or stored somewhere, but that undermines the point of security. This inconvenience becomes especially acute when emailing documents to third parties.
The way Office’s document encryption has evolved over time hasn’t exactly helped. Office 97-2003, used the .doc, .xls, and .ppt formats with something called the Cryptography API (CryptoAPI). From Office 2007 on, Microsoft adopted the Open XML Format’s .docx, .xlsx, .pptx with CNG (CryptoAPI Next Generation).
This, logically, made it tricky to send files encrypted in a newer version of Office to versions based on an older design. Office not only had different file formats but different encryption schemes too.
Office’s encryption defaults:
Office 95, 97 and 2000 – forget it.
Office 2002 and 2003 – used the insecure RC4 stream cipher with a 128-bit key.
Office 2007 – started using AES-128 with SHA-1 hashing.
Office 2010 – Still using AES-128 with SHA-1 hashing but SHA ‘conversions’ doubled to 100,000.
Office 2013 – Still using AES-128 but with SHA- 2/512.
Office 2016/365 – up to AES-256 with SHA-2/512 plus compatibility with Office 2007’s CryptoAPI. (Office 365 additionally transparently encrypts files at rest and during transport).
That we have to summarise Office encryption with a complicated list of overlapping capabilities raises the possibility that one reason people don’t use built-in encryption is because they’re mightily confused about what it offers.
As for ways around encryption, even before Office 2013 got off the ground, Russian pro-crackers Elcomsoft claimed they’d found a way around its apparently bullet-proof encryption. Whether they had or not is almost irrelevant. After years of occasional stories around Office’s encryption, perhaps mud was starting to stick.
It goes without saying, of course, that regardless of the encryption used the same rules apply to Office document passwords as any passwords.
The simple takeaway is that only the encryption offered from Office 2013 onwards is worth relying on, but any encryption is better than none, even versions with theoretical weaknesses. If only Plymouth’s incredibly sensitive spreadsheet had used something.
Encryption is the most powerful, and least used tool for the public. The more stories like this that come out, will people will start to pay attention.
Unfortunately sending to the wrong address itself can break the encryption if they use an Email portal. When you send a typical encrypted portal email, the recipient is offered to create an account and log in to receive the message. So based on that, who ever it was sent to has access, even the wrong recipient.
But this article is about using Office encryption isn’t it and not Email portal encryption?
yes, it’s about Office, it’s also about Emailing secure documents. So I was sharing that the same issue of wrong user getting documents that should have been secure, and that what would be an alternate way of securing documents in email would still have the same problem.
Even following encryption by-the-numbers can be tricky. I once had a client who generated their own assymetric key pair, but then sent me the private key instead of their public key.
Like anything else technical, encrypted traffic between two parties requires experience and intelligence.
One of my wishes is that big companies would spend a lot more effort to make encryption easier to use and easier to understand (more freely available education). If I had my way, I would have a class in grade schools devoted to giving schoolchildren real experience in assymetric key generation and management.
I really appreciate the contributions of the gpg4win and Enigmail teams.
The university sends an email in error. In return its solicitor starts making demands including a response *in writing* no less.
Here’s my response: “Take a long walk off a short dock.”
I know it’s done all the time, but not sending sensitive documents via email would have solved this. If it was instead uploaded to a shared filesystem of some kind, one that both recipients have access to, no one else could have accessed it.
Or, if email was required, end-to-end encryption would also have solved this problem.
In short, I don’t think technology was the problem, and can’t really be the solution. There’s a number of ways it could have been averted, but the user could (or likely would) bypass them all in the name of convenience.
Now there’s a an idea…