Seattle University Alerts Over 2000 Faculty & Staff Of Lost Laptop.

Seattle University announced a couple of weeks ago that an unencrypted laptop was lost while an employee was “commuting on the bus.” An IT investigation drew the conclusion that “an offline email cache file” contained Social Security numbers and other personal information for 2,102 current and former faculty, staff, and dependents.

The story feels like a blast from the (recent) past, seeing how data breaches of this sort have mostly been cut down by the use of full disk encryption (FDE). This particular technology encrypts the entire storage device found on laptops (and, more importantly for the times we live in, in smartphones), ensuring that nothing that is saved on a device can be read by those without the password.

Outside Vendor Involved

In Seattle University’s particular case, file encryption would have done wonders as well:

Although no files with sensitive data were saved directly to the local hard drive, an offline email cache file on the laptop contained attachments with personal information. The main file of concern was the result of an isolated incident in which an outside vendor emailed the file in error.

File encryption encrypts a file only, as the name implies. Had the vendor encrypted the file before emailing it, the data breach would have been averted. Of course, you would have had the same result if the laptop had been protected with full disk encryption.

You’re Still Going to Want FDE…

There was a real push, over ten years ago, for organizations in the US to use FDE on any portable computing devices that stored sensitive data. Among the reasons (other than data security):

  1. It’s much more convenient: you only have to encrypt a hard drive once. Not so with file encryption. If the vendor sends you a file this week, and another file next week, that’s two instances of encrypting files. At some point, someone is bound to forget to do this. Or, perhaps a new employee screws it up the first time around.
  2. It’s all-encompassing: even if a third party forgets to encrypt a file before sending it to you – or perhaps you forget to encrypt a sensitive file that you’ve generated – the use of FDE would mean that the contents of the laptop are protected. If the device is lost or stolen, in a bus or elsewhere, there is no data breach. The protection even extends to files whose existence you’re unaware of, such as temporary files.

What are these temporary files? You may end up with a temporary copy of a file somewhere in the computer if you open a file and work with it. Temporary files are supposed to be deleted at some point, but nobody really knows when it happens. You could search for these files and manually delete them, but it would be time-consuming. Likewise, trying to encrypt these could also be a pain in the neck (and meaningless. Why not just delete them?).

A multitude of data breach events could be resolved with the use of FDE and, thus, in some cases, the push for encryption was very strong. Certain parts of the government, for example, started giving out monetary penalties in the seven figures for information security incidents; however, safe harbor was granted if encryption was used.

Private companies also jumped into action. The main players, one could say, were Apple and Google, who made a tiny but crucial switch, from offering encryption on smartphones as a choice, to making the encrypted state the default (and the only choice in certain cases).

And, such changes made their mark: stories revolving around data breaches from stolen or lost computers and smartphones started to dwindle and then disappear. Of course, they never truly disappear: there’s always the small medical or legal practice or other organization where tiny budgets mean proper security becomes impossible.

That Seattle University, not exactly tiny nor bereft of financial resources, has found itself in this position, in this day and age, is pretty surprising… and, yet, possibly not.

There is an argument that security tools only be deployed according to an organization’s information security needs. So, if an analysis shows that there is no need to, say, secure a particular laptop, then you don’t have to (some even argue that you shouldn’t: the cost of “unnecessarily” securing a laptop could be diverted to another device that really needs it).

… Because You Really Can’t Account For It All

At least, that’s the theory. Reality tends to be different. While you can’t go crazy with security (costs can really add up and there could be a tremendous impact in operational efficiency), you can’t proclaim that a particular piece of computing equipment doesn’t need any (real) protection whatsoever, especially if, sooner or later, something could be saved on it that could trigger a data breach. There are a million ways that this could happen.

For example, a user could be meticulous in terms of never saving sensitive material on his computer (including the generation of temp files with sensitive data) and still be predisposed towards a data breach because later on, he gets copied on emails with attachments that contain sensitive material (maybe he got promoted or is covering for his boss, so her emails come his way).

Or, perhaps he is the wrong recipient to an email that contains sensitive material. It’s not his fault, but if it’s his laptop that gets lost or stolen, he is the reason for the data breach.

Ultimately, with Seattle University, the question boils down to this: Why was the laptop in question not encrypted? Was it because an analysis showed that it didn’t need it? In hindsight, that was the wrong conclusion. Or, was FDE not installed by mistake? If so, there’s a good chance that the university would need inspect its security processes, since it’s likely that there are other time bombs ticking.

Related Articles and Sites:
https://www.databreaches.net/seattle-university-laptop-containing-2000-social-security-numbers-lost/
https://www.seattleu.edu/data-security-incident/
https://www.seattletimes.com/seattle-news/seattle-university-laptop-containing-2000-social-security-numbers-lost/



Comments (0)


Let us know what you think