AlertBoot Endpoint Security Blog

HIPAA/HITECH Data Breach Reports: Incidents Involving 500 Or Less To Be Reported By End Of February

sang_lee — Wed, 08 Feb 2012 11:57:00 GMT

The site jdsupra.com has a short but urgent observation that February is the month when all HIPAA covered-entities must report any incidents which involved 500 or less PHI data breaches. Again, a stark reminder that if you are a covered entity, it pays in the long run to use drive encryption software like AlertBoot.

More than 500 Affected

The "HITECH Interim Final Rule for Breach Notification for Unsecured Protected Health Information" stipulates that HIPAA covered entities must report a data breach to the Department of Health and Human Services without undue delay if it involves 500 or more people.

This requirement is exempted if the PHI data breach was nullified via the use of encryption software. While neither HIPAA nor HITECH codifies it directly, an entry in the Federal Register clarifies the situation (my emphasis):

...if a covered entity chooses to encrypt protected health information to comply with the Security Rule, does so pursuant to this guidance, and subsequently discovers a breach of that encrypted information, the covered entity will not be required to provide breach notification because the information is not considered ‘‘unsecured protected health information’’ as it has been rendered unusable, unreadable, or indecipherable to unauthorized individuals. On the other hand, if a covered entity has decided to use a method other than encryption or an encryption algorithm that is not specified in this guidance to safeguard protected health information, then although that covered entity may be in compliance with the Security Rule, following a breach of this information, the covered entity would have to provide breach notification to affected individuals. [Federal Register Vol.74, No.162]

But what about incidents where encryption is not used and less than 500 people are affected?

Less than 500 Affected

If a data breach involves less than 500 patients, then it and any other similar instances can be consolidated into one report to be sent to the HHS at the "end of the year." The end of the year is a misnomer because it's really 60 calendar days after the new year has begun. In other words, by the end of February of each year, a covered entity must file a "data breach that affected 500 or less" report.

The report is done electronically from the hhs.gov site. Follow this link.

Data Encryption: Fricosu Case Offers New Problem. Defendant Doesn't Remember Password

sang_lee — Wed, 08 Feb 2012 02:51:00 GMT

I figured this would happen. I haven't mentioned it in my coverage of US v. Fricosu, but once the judgment was handed down that Ramona Fricosu must provide decrypted evidence, I wondered whether she would make the claim that she forgot the password. Such things happen quite often when it comes to data encryption software.

You see, the situation has been on-going since 2010. I don't know about readers of this blog, but in my experience, not typing a password in over one year tends to lead to "password amnesia." This is not the case if you only use one password, like I used to do in my younger days. In fact, I can still tell you what it was, over ten years later (but I won't).

But once you graduate to more secure practices and start using multiple passwords, your memory starts to get a little sketchy. At least, mine does.

In Contempt? Or Being Honest?

I've already blogged that I thought that the judge's decision in the Fricosu case was pretty straightforward. I still do; however, there are aspects to it that troubled me then, and still trouble me now, especially because of the above development.

The thing that always troubled me is: what if a person doesn't remember the password anymore? I've been thinking about this on and off since I found out about the UK's RIPA, the Regulation of Investigatory Powers Act. Under RIPA,

"...a suspect [is given] a time limit to supply encryption keys or make target data intelligible. Failure to comply is an offence under section 53 of the same Part of the Act and carries a sentence of up to two years imprisonment, and up to five years imprisonment in an investigation concerning national security."

To quote myself:

...what if you honestly don't remember the password? If you're in the habit of encrypting a design for the world's best toaster-oven because you're afraid of industrial espionage, and happen to forget the password to unlock it...should you go to jail for it?

That's assuming the government ends up believing your encrypted toaster-oven designs are actually, I don't know, terrorism-related information.

The decision surrounding this latest development will be (my apologies to Ms. Fricosu whose life must be a living hell right now) the really interesting question to answer. The decision to force Fricosu to provide decrypted data was pretty straightforward, I thought.

But this latest twist? The government doesn't have taped conversations revealing that Fricosu remembers the password, as far as I know. They can't prove that she doesn't remember it. Or that she does remember it, for that matter. I'm sure that forcing her to reveal the password, in an attempt to use it as a framework for generating other passwords, is a violation of the Fifth Amendment (the last ruling makes it abundantly clear that it would, and that's why she's not being forced to provide a password but decrypted information).

This is probably the worst post on which to push our managed disk encryption services from AlertBoot. And yet, I can't help but think that if someone out there is placed in the same situation and is being accused erroneously of a crime -- and the contents of the laptop will actually work to clear his name -- he'd probably think it's a godsend that he can have his AlertBoot encryption password reset after a quick confirmation of his identity.

Related Articles and Sites:
http://www.wired.com/threatlevel/2012/02/forgotten-password/

Drive Encryption: Department of Child Services in Hendricks County Laptops Stolen

sang_lee — Wed, 08 Feb 2012 01:41:00 GMT

According to wishtv.com, the Department of Child Services in Hendricks County (Indiana) reported the theft of multiple laptop computers with sensitive information over the weekend. However, they can be congratulated for stopping a full-blown data breach from occurring: laptop encryption software like AlertBoot was used to secure the data in the computers.

Department is a Block Away from Cops

Two TV projection screens and 10 laptops were stolen during the break-in. Even more audacious on the part of the thieves is the fact that Department of Child Services in Hendricks County is a block away from the Avon Police Department.

Due to the nature of the department's activities, it's not a stretch to assume that sensitive information must have been handled on the stolen laptops. However, encryption software was used to secure that information. This nearly guarantees that the laptops won't be accessed by the thief or thieves.

Encryption is Scrambling

WISH-TV Engineering Manager Tom Weber explained the concept of encryption like this: "Encryption is scrambling."

Well...yes. But it's a little more than that. If I may play off the word "scrambling," the use of encryption can be compared to the following:

Take an egg. Crack it and scramble it. Serve on a dish. Now, try to reconstitute the scrambled eggs into the original egg. This is what encryption is like.

The egg is your data. Scrambling is the encryption process. But, unlike the actual egg, you can actually reverse the scrambling process when it comes to data encryption. All you need is the encryption key, which is generally linked up to a password (to make it easier to remember). If a person were to try to force their way into the encrypted data, they'd find is as hard as trying to unscramble a plate of eggs Benedict.

No wonder, then, that those who require the safeguarding of sensitive data use encryption.

Full Disk Encryption: Stolen Univ. Of Miami USB Drive Affects 1200

sang_lee — Tue, 07 Feb 2012 06:34:00 GMT

The theft of a USB flash drive from a University of Miami doctor's vehicle has led to the breach of patient information affecting 1,219. Drive encryption like AlertBoot wasn't used to protect the patient data, apparently. As a result, the University of Miami is approaching patients with news of the event, per HIPAA/ HITECH requirements.

UM Posts FAQ

According to a frequently asked questions (FAQ) posted by UM, the car belonged to a Pathologist from the University of Miami Miller School of Medicine. The rear window was broken and a briefcase containing the USB drive was stolen.

Not that it should matter, but the profession helps to explain why the USB pendrive contained (my emphasis):

limited data elements of certain patients who had specimens reviewed by the department of Pathology between 2005 and 2011. This information included name, medical record number, age, sex, diagnosis and treatment information. No financial information or social security numbers were stored on the stolen drive.

Normally, six years worth of data on anything is a lot of data to be carrying willy nilly. For a pathologist, though, this could merely be chicken feed for a larger project tracking the spread of a particular disease through decades.

Which is all the more reason why this particular device ought to have been protected with encryption software: if the user knew that he or she'd be gallivanting around with years and years of data, all the more reason to have the data container encrypted.

HITECH Requires Notification

The University of Miami notes upfront in its breach notification letter that patients are being notified of the incident due to the US HITECH Act. HITECH contains an update to the decades-old HIPAA, the Breach Notification Rule.

This rule requires that breached medical entities (technically, HIPAA covered-entities) notify patients of any PHI data breach breaches, PHI standing for protected health information. Under the rules, nearly anything that can identify a patient is considered to be PHI, including names and addresses.

If more than 500 are affected, the breached entity (UM in this case) must take the breach public by notifying state media and/or making a posting on their website. The Department of Health and Human Services must also be alerted, who will eventually post the breach on their "Wall of Shame."

Patients must be notified regardless of how many are ultimately affected. They must be sent a letter, although contacting them via other methods is possible under certain conditions. One thing that I've noted, and which I think UM might have failed to comply with, is that patients must be notified within 60 calendar days of the breach's discovery.

Now, I know December and January have 31 days each, and the breach occurred on November 24. This means that, by any measure, UM has violated the Breach Notification Rule, unless (1) the media has gotten hold of this story one week after UM went public with it or (2) the breach discovered until much later than November 24.

My guess is that #2 is what UM was dealing with. Thanksgiving Day fell on that date, ironically enough. I can already picture it: pathologist comes back from the holidays, say, a week after, and finds the car window broken. Goes into panic mode. A day passes and the situation regarding the USB drive dawns on him or her, and gets in touch with the employer.

UM Already Encrypts Laptops

In the FAQ, the University of Miami noted that the establishment already uses encryption software to protect their portable medical computers. In other words, whole disk encryption.

One of the setbacks (the contra in "pros and cons") is that disk encryption protects the disk. People think it protects the data, but it doesn't. It protects the disk by encrypting the disk. And, because the disk is encrypted, any data saved to the disk is also protected.

Yes, it sounds like I'm splitting hairs, but there's a reason behind this pedantic madness. If I point out the above to you, you'll easily grasp and understand that data copied off of an encrypted disk is not protected anymore. Why? Because disk encryption protects the disk, not the data.

It's the reason why many encryption software vendors offer ways to protect what's going on with your computer's USB port. AlertBoot, for example, offers gratis the ability to encrypt USB devices automatically whenever they're plugged into an already-encrypted computer.

I'm certain UM could have used such a program (in hindsight).

Laptop Encryption Software: Podiatrist Laptop Stolen in Hampshire (UK)

sang_lee — Tue, 07 Feb 2012 01:44:00 GMT

The BBC and other sources bring us news of a patient data breach at the "Walking On Air" clinic in Gosport, Hampshire (UK). A laptop computer was stolen containing personal and medical information for 1,500 people. The device was not protected with disk encryption software like AlertBoot but password-protection was used.

Questionable Approach to Data Security

Walking On Air, as the name subtly implies, is a podiatric clinic. The BBC has a picture of the establishment in their article and I've got to admit that it'd be quite easy to steal something from them: the entire façade to the clinic is glass. Not much physical security there.

Encryption software, it could be argued, was made for situations like these, where the need to keep data secure is extremely high (nearly 1,500 people's personal information and medical patient notes were lost in this case) and yet it's impossible to match that need with physical maneuvers.

And yet, the podiatrist didn't use it:

Ms Townsend [the podiatrist] said: "It's got personal information on it but mostly all my medical patient notes which I need.

"I didn't really know much about encryption and things like that. I'm not very good with computers."

The BBC notes that Ms. Townsend did use a password on the computer. Of course, password-protection is not really data security. I've made this observation many times before. But, there are many, many people out there that equate the one with the likes of disk encryption, which also uses a password. The difference is night and day. Like the difference between a real gun and a water pistol.

What I really want to question, though, is: how can a person who is a medical doctor be so illogical when it comes to data protection? "Don't know much about encryption" but decided to go ahead and do it alone? And not do it right?

Apparently, Podiatrists are Not Doctors in the UK

Then, I thought, wait: are podiatrists doctors? In other words, are they medical doctors? Because I thought they were, but the above podiatrist planted some seeds of doubt with her brilliant words and logic.

In the US, the answer is a resounding yes, they are doctors. They go to school, have to complete a two-year residency, prescribe drugs, give x-rays, and can even operate on the foot. (Podiatrists, apparently, don't get an MD or DO degree but a DPM -- Doctor of Podiatric Medicine -- but this allows them to practice general medicine).

In the UK, however, the story appears to be different. I've trolled many sites and it appears that podiatrists in the UK are not considered doctors. There are many reasons, but the issue appears to mainly revolve around the level of education: the level of training and studies is just not there. This site's discussion appears to be most informative of all the sites that I've visited.

Of course, this information is neither here nor there when you consider what this site is about: encryption and data security. I just thought it was interesting, though, how you can have something that on the surface appears to be the same but a dissection on abilities, accreditation, testing, etc. can have such a profound impact.

Why, it's like the difference between encryption and password-protection.

Tablet Encryption: Motorola Sells Used Xooms With User Data Unwiped

sang_lee — Sat, 04 Feb 2012 02:28:00 GMT

The WSJ reports that Motorola was caught selling pre-owned (technically, refurbished) Xoom tablets with the prior owner's data on it. I've often noted that the use of data encryption like AlertBoot is a precautionary measure because you never know what might happen. This is not quite what I had in mind.

Woot!

According to wsj.com, 100 of 6,200 Xooms sold via woot.com may have contained personal data such as email and social media passwords. I guess Motorola failed to erase the devices properly. Not that the previous (temporary) owners of the devices ought to be blamed, but if they had turned on the encryption software setting for their Xoom tablets, they wouldn't have this problem. From the Motorola site (my emphasis):

Motorola XOOM - Data Encryption
Does the Motorola XOOM support data encryption?
====================
Yes, the Motorola XOOM does support data encryption.

You can encrypt your accounts, settings, downloaded applications and their data, media, and other files. Once you encrypt your tablet, you can't unencrypt it except by performing a factory data reset, erasing all the data on your tablet.

Encryption takes up to an hour. You must start with charged battery and keep your tablet plugged in until encryption is complete. If you interrupt the encryption process, you will lose some or all your data.

Since Motorola was reselling these, they had to make sure that it looked and operated as close to brand new as possible. I'm an iPad user myself, but I assume that with encryption turned on, a password is always required to access the device. Otherwise, what's the use, no? It'd be like taking an extremely expensive personal safe and using it as an open bookcase.

Anyhow, consider Motorola's position: here's a device that's about to be sold as a refurbished item and nobody can get in the device because of the password. What do they do? Reset the encryption (i.e., blow away the encryption key), erasing all the previous data in the process. In fact, I'd probably do it the lazy way: 10 wrong password entries and Bob's your uncle.

Do You Carry Around a Data Device? Encrypt It

Regardless of what the device happens to be, if you carry sensitive data on a digital device, you're best off using full disk encryption on it. What is full disk encryption? As the name implies, it's when the entire hard disk is encrypted so that the contents are protected no matter what. This way, there are no loose ends when it comes to your data security. For example, you won't be left wondering whether that last file you received via email was actually encrypted or not.

As you can see from Motorola's explanation, disk encryption takes a little time to complete. In fact, it's directly proportional to the capacity of the storage media: generally, the bigger it is, the longer it takes. The speed of the CPU, the amount of RAM, and other factors do play a factor, but the biggest by far is the capacity. After all, we're talking about encrypting every single bit, every single byte, every single sector on the disk.

But, it's worth the wait. You only need to encrypt it once -- unlike file encryption, which requires one to go through the encryption process each time you create a new file -- and after that your only worry is trying to not forget your password.

(Of course, managed encryption service providers like AlertBoot have ways to reset your password after confirming your identity, as well as providing reports for monitoring and audit purposes. That's the beauty of having a third party manage stuff for you.)

Drive Encryption Software: Two Laptops Stolen From Oldendorf Medical Services

sang_lee — Fri, 03 Feb 2012 02:50:00 GMT

Oldendorf Medical Services, in Albany, New York, has announced data breach. According to a short piece at timesunion.com, two laptops were stolen during a break-in on January 18. The laptops contained "minimal clinical information." Whether this information was protected with hard disk encryption was not mentioned.

But, seeing in what capacity the computers were being used, I'd say it's safe to say that the equivalent of AlertBoot endpoint security was not used.

Doing It Old School: Picked Locks

The computers did include SSNs and other information for some.

A suspect is in custody for picking the locks to Oldendorf Medical Services's offices and stealing two laptop computers that were being used with cardiac test machines. One of the computers was "a pulse volume recording 'PVR' and the other was an endothelial peripheral arterial tone, or 'endopat.'" Both are used to detect coronary atherosclerosis, according to timesunion.com.

Computers that are part of medical equipment are generally not encrypted. While I'm not familiar with the reason why, I've always imagined it was due to compatibility issues. What these issues could be, I have no idea. However, it's the only explanation that makes sense, since medical equipment by definition collect patient data -- data that is considered protected health information (PHI) and requires protection under federal and state law.

A Little Crazy

That's not to say that it's impossible to protect PHI with encryption software when computers and medical equipment meet. I've had a chance to review medical equipment catalogs last year, and many of them mention how their such-and-such equipment now features AES-256 encryption and what not.

So what gives? Why now? I'd opine that it's based on a confluence of different forces.

First, progress in the technical arena. It's only within the past 10 years or so that computers have grown so powerful that the impact of full disk encryption software has become imperceptible. Also, backing up and storing data has also progressed to the point where it can be called "automated." Nothing worse than finding that your patient data is in an encrypted computer that just died...and you don't have copies! Management of keys and such has also only recently become something other than overbearing.

Second, updated regulations and laws. Even today, the use of encryption is not mandatory in medical settings. However, HITECH, HIPAA amendments, and other federal and state laws make it almost impossible not to use encryption when it comes to PHI protection. While I won't go as far as saying that encryption is a selling point, the lack of it could very well be grounds for choosing someone else. Such laws and regulations have only been passed in the past 5 years or so.

Third, better public understanding. Let's get something straight: the odds of a patient coming into a clinic or other medical organization and inquiring whether their medical information is encrypted before subjecting themselves to a surgery, checkup, examination, etc. is close to nil. But, in the event of a data breach, you'll see that for the most part, it's the covered entities that didn't use encryption that pay dearly, be it in the courts or elsewhere.

Cost Of Data Breach: Stratfor Sued For $50 Million

sang_lee — Thu, 02 Feb 2012 13:09:00 GMT

It looks like I won't be stopping coverage of Stratfor any time soon. According to statesman.com, Stratfor -- the international geopolitical analysis company that was hacked by Anonymous about one month ago -- has been presented with a lawsuit for more than $50 million. This is independent of whatever fines Startfor will pay for violating PCI-DSS requirements, if any. Is it possible that just a dab of data encryption and common sense could have prevented all of this?

Accused of Negligence

From the statesman.com:

The New York lawsuit, filed by David Sterling of Woodbury, N.Y., accuses Stratfor and its management of negligence, breach of contract and violation of the federal Stored Communications Act in allowing its customers' information to be stolen and in not notifying customers about the theft for more than two weeks after it occurred.

The suit says Stratfor failed "to take reasonable steps to secure" its computer systems from outside attack. It also says Stratfor kept information about the hacking attack secret from its customers.

I've covered the Stratfor situation here, here, and here. In summary: Starfor didn't encrypt client information, and it turns out that passwords were not salted.

Is this enough for a charge of negligence? I'm not a judge, so what I think doesn't matter, but here are my two cents: it's not negligence. But it comes pretty close.

You see, that encryption software protects data is not a big secret. Likewise when it comes to protecting credit card information: there are industry rules -- and I mean rules, not guidelines -- that require credit card info to be encrypted if stored. Another not-so-big secret. Plus, the entire hash-salting fiasco: salting passwords before hashing them is established practice, and has been for decades.

This is an intelligence firm, dealing with defense personnel all over the world. Are we to believe that they had no idea that encrypting information was important?

Of course, the use of cryptographic solutions does not guarantee 100% that Anonymous wouldn't have laid their mitts on the information that was breached. But let me tell you, accusations of negligence are less likely to hold sway if encryption was used.

Hospital Laptop Encryption Software: Lexington Clinic Notifies 1018 Of Data Breach

sang_lee — Thu, 02 Feb 2012 00:13:00 GMT

A laptop computer was stolen from Lexington Clinic's Neurology Department, "despite stringent security protocols." What these protocols refer to is not specified. However, seeing how Lexington Clinic is "following all requirements of the American Recovery and Reinvestment Act of 2009 and the Health Information Technology for Economic and Clinical Health Act by notifying patients of the breach," I'd say it's quite safe to note that drive encryption software like AlertBoot was not used in this particular case.

Some PHI Breached

The laptop was stolen on December 7, 2011 from the neurology department at St. Joseph Office Park at 1401 Harrodsburg Road, in Lexington, Kentucky. According to kentucky.com, it took weeks to figure out what information was on the laptop, which was used with the clinic's electromyography machine.

However, in keeping with HITECH, the clinic had to make a disclosure before 60 business days had passed since the discovery of the breach. Seeing how the theft occurred on December 7 and was discovered on December 8, the notification comes towards the latter end of the 60-day rule: January 30 marks the 53rd day.

The computer contained names, contact information, and diagnoses for a number of patients that sought the neurology department's services, some going as far back as 5 years. It did not include SSNs, credit card numbers, bank account numbers, and other financial information.

Regardless, Lexington Clinic is asking any affected patients to "stay alert for signs of identity theft":

Accounts you didn't open and debts on your accounts that you can't explain.

Fraudulent or inaccurate information on your credit reports, including accounts and personal information, such as your Social Security number, address(es), name or initials and employers.

Failing to receive bills or other mail. Follow up with creditors if your bills don't arrive on time.

Receiving credit cards that you didn't apply for.

Being denied credit, or being offered less favorable credit terms, like a high interest rate, for no apparent reason.

Getting calls or letters from debt collectors or businesses about merchandise or services you didn't buy.

HIPAA Breach? Not So Fast

There are many that might jump up and ask, "hey, isn't this a HIPAA breach?" Not necessarily. Sure, the fact that patients and the media are being notified (under HITECH, which amends HIPAA, if more than 500 patients are affected, the covered entity must contact local media and disclose that data was breached) indicates that encryption software was not used on this laptop.

It's an assumption that encryption wasn't used, of course. I'm of the opinion that most hospitals, clinics, and other medical organizations and agencies wouldn't want negative coverage, if avoidable, so the use of encryption would lead to bupkus in the event of a laptop theft; it's perfectly legal under HITECH. Plus, with the use of cryptographic solutions, it's not just a legal loophole. Technically, that data is safe no matter how the laptop thief tries to force his way into that device. (This, however, does not preclude a hospital from using encryption and going public with the breach. I can think of at least two occasions where this happened).

Anyhow, returning to the subject at hand: this might not be a HIPAA breach. After all, consider the situation: the laptop was not stolen from a car, or an employee's home. It was stolen from the clinic. Strike one. I'm assuming that the clinic offered a certain degree of physical security.

Second, the laptop did have "stringent security protocols." Again, it's pretty evident that encryption was not part of that security protocol. However, nothing within HIPAA states that encryption must be used. Encryption is known as an "addressable" issue: if a hospital thinks encryption is not necessary, they don't have to use it as long as there other security measures in place.

Still, encryption is advisable even if it's only addressable: not only is it a better form of securing data, it's the only way to get out of the Breach Notification Rule under HITECH. It's win-win, for covered entities and patients alike.

Plus, a solution like AlertBoot not only protects laptops' contents, it also makes conducting audits and monitoring easier. Its built-in and fail-safe encryption audit reports allow a covered-entity to quickly prove that a stolen laptop conforms with HIPAA and HITECH.

Disk Encryption Software: Regions Financial Corporation USB Data Breach

sang_lee — Wed, 01 Feb 2012 13:05:00 GMT

Current and former employees of Regions Financial Corp are facing a data breach after a USB flashdrive that was mailed went missing. The USB device was protected with data encryption software. This is a good thing. However, the information to decrypt the data was also mailed in the same envelope as the USB device.

Ernst & Young to Blame

The Regions Financial data breach was actually caused by outside auditor Ernst & Young. An employee mailed the flashdrive and the "decryption code" in the same envelope to a different branch. When the mail arrived at its destination, the USB drive was missing. The decryption code was still there.

Employees of Regions were alerted of the breach via a letter dated January 23. The breach took place in November. Information about 401k plans were lost, including names, SSNs, and possibly dates of birth.

The situation is ironic: E&Y has released studies concerning data security. Less than two years ago, it had noted that secondhand flashdrives were chock-full of sensitive data. If I'm not wrong, they had also pointed out the need for encryption, or at least the use of better data deletion techniques.

I don't really remember if they had pointed out why keeping the passwords for accessing encrypted data and the encrypted data in the same place is a bad idea. On the other hand, do you really need a multi-million dollar consultancy firm to point out the truly obvious?

Pick Up the Phone

What should the employee have done? Obviously, I don't have a problem with sensitive data being sent over regular mail, as long as disk encryption was used to secure the data. But, doing so poses problems. How does one let the recipient know what the password is?

Putting the password in the same envelope is a bad idea. Putting the password in a separate envelope and mailing it is acceptable. Some might to turn email, but this also poses a problem: what if the email address is a shared one? Or, what if the recipient's company has set up a policy where all emails are copied between a particular group's members?

The best way to divulge the password might still be via the phone. Once the recipient has the USB device in his hands, he picks up the phone and calls the sender. Of course, there's also the possibility of a phone being tapped.

All methods of sharing passwords are fraught with the possibility of a leak. Some, however, are much higher than others.

I should also note that the fact the decryption code was still in the envelope is meaningless: anyone could have taken and made a copy of it.

Data Encryption: Midlothian Council First Scottish ICO Fine, Largest To Date

sang_lee — Tue, 31 Jan 2012 00:50:00 GMT

In a clear sign that it frowns on all data breaches, not just electronic ones, the UK's Information Commissioner's Office (ICO) has handed out its largest penalty to date to the Midlothian Council in Scotland. It's the first ever ICO fine for any Scottish local government, and it underscores that, while laptop encryption software like AlertBoot goes a long way towards placating any concerns, it's not the only thing UK data controllers should be focusing on.

Five Breaches in Four Months

While it's true that the Midlothian Council has received the largest penalty to date (£140,000. The next largest one is £130,000 handed to the Powys County Council in December 2011. I keep a list of ICO monetary penalties), one could also argue that it's not a fine, but a total fine for 5 data breaches:

The wrong child's name was entered into an agreement

A GP was sent a request for a child's report. The child wasn't registered with the GP

A file was unintentionally included with other documents and sent to unintended recipients

Minutes of a child's protection conference were sent to an old address

A letter on the foster care status of a child was sent to the wrong people

The above occurred in a period of 4 months. It could be argued that each breach cost the council £28,000, putting it at the bottom of the pile.

Incidentally, the £140,000 was the reduced figure from £150,000 after the council appealed the fine.

Human Error? They Usually Are

From scotsman.com:

Midlothian Council said it referred itself to the commissioner and insisted its procedures were sound, despite the breaches.

Colin Anderson, chief social work officer, said: "While the council accepts there were mistakes, they were caused by human error. Clear procedures were in place but were not followed."

That the breach was a result of human error is a moot point: that's usually the case when it comes to the ICO handing monetary penalties. With respect to the UK data breaches I've covered on this site, especially those that have involved a penalty from the ICO, almost all of them involved human error. That is, I can't really recall a breach where someone caused the breach on purpose.

That "clear procedures were in place but not followed" appears to exacerbate the situation, in my opinion. In fact, if the procedures were so clear but ignored, couldn't one argue that this was not a case of human error?

Ruling on Fricosu: Much Ado About Nothing?

sang_lee — Sat, 28 Jan 2012 00:29:00 GMT

The ruling by US District Court Judge Robert in US v. Fricosu has attracted a lot of attention. It was covered by various media outlets who, in my opinion, largely got it wrong (at least, if you're only reading the headlines). I'm not a lawyer, but there are plenty of those who are that have opined on the case in their blogs and elsewhere. Opinions are divided, as it should be. The case was a controversial one.

Based on what I've read, it looks like there may less here than meets the eye. That is, this case is not a precedent setting case where the US government can get a copy of your encrypted data whenever it wishes to. Nor is it correct to state that "decrypting a laptop doesn't count as self-incrimination."

Rather, as others have noted, it's a similar case to Boucher, where a court found that Fifth Amendment rights were not violated because of "foregone conclusion."

Clearing Up Past Posts, Laying Down the Facts

I've covered the Fricosu case twice in the past, here and more recently here. I had to go with what I could find on the internet, so some of the information on which I drew my opinions were factually incorrect.

On reading the actual Judge's ruling, we get a clearer picture of what transpired. Just laying out the facts:

Fricosu lived with her mother and her children (earlier stories alluded to roommates)

Six computers were seized when the search warrant was effected

Three computers were desktops, the other three were laptops. Only one of them was encrypted with "PGP Desktop"

The encrypted computer was found in Fricosu's room

When booted, the computer displays the whole disk encryption screen, in which the machine is identified as RS.WORKGROUP.Ramona (earlier stories noted that there was no way to identify who the owner of the computer was)

A conversation was recorded between Fricosu and Scott Whatcott, her previous husband and partner in crime (and incarcerated at Four Mile Corretcional Center at the time of the conversation)

The conversation runs as follows (my emphasis. It's slightly long; my apologies):

Ramona: Oh so anyway, earlier we were talking about that lawyer thing
Scott: Yes
Ramona: So um, in a way I want them to find it
Scott: OK
Ramona: in a way I don’t just for the hell of it
Scott: OK
. . . .
Ramona: Ookay (pause) uhm in a way I want them to find it
Scott: Mm-hmm
Ramona: and uhm because they will have to ask for my help uhm and in another way I don’t want them to find it let them let them work for it
Scott: Right
Ramona: you know what I mean
Scott: right (pause) yeah, if it’s there, they, they will find it
Ramona: uhm, can they get past what they need to get past to get to it
Scott: they will listen first
Ramona: it will shut off
Scott: (pause) what
Ramona: it was on my laptop
Scott: oh yeah
Ramona: yeah
Scott: OK
Ramona: I don’t know if they can get to it
Scott: it was on your laptop
Ramona: yes
Scott: OK (pause) and did you have any something like anything on your computer to protect it or something
Ramona: yeah
Scott: OK then I don’t know.
Ramona: I mean, I think I did
Scott: OK
Ramona: Ya know I haven’t
Scott: (SC [simultaneous conversation]) oh yeah that’s right it was on your laptop wasn’t it
Ramona: I think so but I’m not sure
Scott: OK
Ramona: yeah cause they kept asking me for passwords and I said, ya know no I just didn’t answer them
Scott: right (SC). Because when you went there you took your laptop
Ramona: yeah I think so I think I did
Scott: and so (SC) it would been on there
Ramona: yeah
Scott: OK
Ramona: and my lawyer said I’m not obligated by law to give them any passwords or anything they need to figure things out for themselves

While there is nothing conclusive in the conversation, it's quite obvious that there is something of an incriminating nature in one of the laptops, based on the facts that I've listed above, Not just any laptop, though; one that requires a password for access. Which has also been identified as Ramona's, per the name on the computer.

Is It a Foregone Conclusion?

Earlier this month, I noted that a defendant had to cough up his encrypted hard disk's data in another case involving a cryptographically protected laptop. To summarize the case, a man, Mr. Boucher, had given a US Border guard access to his computer, on which child pornography was present. The man was detained for this. When the government booted up the computer again, after the arrest, full disk encryption stopped them from accessing the evidence.

The court ruled that an unencrypted copy of the disk's contents had to me made available by the defendant because the government already knew that the evidence was in the laptop. Producing this evidence was not in violation of the Fifth Amendment because of the foregone conclusion doctrine. That is, producing the evidence is not self-incrimination because the government already knows about it: where it is, what is looks like, etc.

The question is, does the foregone conclusion doctrine apply in the Fricosu case? According to the judge, yes it does. Based on the evidence and the taped conversation, it's not far-fetched to say that the government knows of the existence of evidence; that's it's on Ramona's computer; and that a password is required to access it.

Of course, the situation is not as clear-cut as the Boucher case because no government official has actually seen it on the computer, nor do they know, based on the conversation, what type of evidence it is (images, spreadsheets, a word processing document, etc).

There is also the question whether Ramon's computer is, in fact, Ramona's. Sure, it's labeled as such, but this wouldn't be the first time a computer is set up one way and passes its ownership unchanged. On the other hand, I'm led to believe that there was only one computer that was protected with a password, meaning that Ramona's computer could be easily identified: just look for the one that demands a password.

So, to summarize, there's a computer in Ramona's room, named Ramona, which is the only one that requires a password to access, and, according to a taped conversation, there's certainly a computer that belongs to Ramona which requires a password.

I don't know. I'm inclined to think that the encrypted laptop is Ramona's.

What I Didn't Know About the Fifth Amendment

Amidst all the articles, comments, and opinions, some have been especially helpful in understanding the situation.

One of the commentators at the site volokh.com gives this helpful explanation:

The 5th amendment is a protection against compelled testimony incriminating oneself. However, you don't have a right to refuse to turn over incriminating evidence — such as documents, video or records of any type.

The issue in the instant case is the defendant was arguing that divulging the password would show that the defendant had ownership/control over the computer — that, not the information that was already contained on the hard drive, is the testimonial aspect. The court simply found that the Feds already knew and could prove that the defendant had ownership/control over the computer and therefore there was no 5th amendment privilege that attached. The contents of the drive may incriminate the defendant more but those contents are not testimonial in nature — only the act of divulging the password is testimonial and the defendant's ownership of the computer has already been established so she is not going to be further incriminated by giving up the password. [volokh.com, disintelligentsia]

The definition of testimony, under the law, according to Wikipedia:

In the law, testimony is a form of evidence that is obtained from a witness who makes a solemn statement or declaration of fact. Testimony may be oral or written, and it is usually made by oath or affirmation under penalty of perjury. Unless a witness is testifying as an expert witness, testimony in the form of opinions or inferences is generally limited to those opinions or inferences that are rationally based on the perceptions of the witness and are helpful to a clear understanding of the witness' testimony.

What the government is seeking is not testimony.

Also from volokh.com:

I think some folks are hung up on the "foregone conclusion" notion.

If the police have a warrant to search the defendant's office for documentary evidence of a criminal fraud and find a locked file cabinet, the warrant reaches the contents of that cabinet. Issues about: (1) "expectation of privacy" in a locked cabinet; or (2) "proof" of what the government believes is in the cabinet are now irrelevant issues. Whatever may be inside is reachable by the police because they already satisfied the Fourth Amendment and got a warrant. This is true even if the cabinet contains evidence of a wholly separate crime, like possession of child pornography.

It has long been the rule that a defendant does not "testify", against him/herself by handing over the key to the cabinet, nor by telling the police where the key is. This is true UNLESS the identity of the owner of the cabinet is in doubt. That's why police questioning resulting in, "here's the key to my cellar door" does not raise Fifth Amendment concerns, while "give us the key to the door behind which the loot is stashed" does. [volokh.com, FmrADA]

Based on what I've covered so far, I'd say that the judge's decision was, strangely enough, pretty straight-forward. I say strangely enough because, if it's so straight-forward, why all the controversy? Especially among those who don't appear to be flame-baiting trolls?

Fricosu - Questions Remain

If you go to the volokh.com site (link below), you'll see a very spirited discussion why. Some pertinent questions:

Can you say that plain text data "exists" when it's encrypted?

What if you actually don't remember the password?

What if the information is doubly encrypted?

Is encryption like a digital safe or something else completely?

And others

As far as I can tell, the controversy can be summarized like this: let's say that you have a paper document, encrypted by hand, inside a locked safe. The court orders you to produce the contents of the safe. Do you only produce the key to the safe? Or do you also have to decrypt the document?

If disintelligentsia and FmrADA's comments are correct, the document has to be produced in its decrypted form, if the government knows (or can prove that it knows) that the document is incriminating evidence -- even if the government doesn't know what the document's contents are, exactly. The fact that the document is encrypted is immaterial, since the government knows that its contents are incriminating evidence. And, producing it is legal because it's not testimony.

On the other hand, if the encryption key exists in the defendant's mind (it's not written down somewhere), then that is testimony. Does forcing a person not to provide the encryption key but only the decrypted contents provide a way to legally gain access to the document's contents? It looks like we'll have to wait for a decision from the higher courts.

There are, of course, other approaches listed to explain why the Fricosu decision is wrong...and why it's right.

If I've learned one thing that's unequivocally certain from this case, it's that this case definitely does not claim that decrypting a laptop or giving your password out is not a violation of the Fifth Amendment. If anything, it appears that every care and effort has been made to ensure that such a claim cannot be made. The correct headlines should have been "decrypting a laptop or giving your password out is not a violation of the Fifth Amendment...under certain conditions that have applied for decades."

Disk Encryption Software: Follow Up On Edmonton Public School Board Data Breach

sang_lee — Wed, 25 Jan 2012 02:33:00 GMT

The Canadian Office of the Information and Privacy Commissioner has finalized its investigation on the Edmonton Public School Board breach, nine months after the incident took place. If you'll recall, a USB disk was lost. A number of the school's IT policies had been broken, including the non-use of data encryption software.

More Information Revealed, Not Much Changed

I had covered the incident back in April 2011. It looks like there isn't much more to report, although a number of details have been cleared up.

More than 7,600 employees of Edmonton Public School District were affected by the data breach. Of these, 2,826 had "considerable personal information, including social insurance numbers, banking information or both" in the lost USB disk. The remaining 4,836 had minimal information stored in the unsecured device.

The data included but was not limited to:

employment applications, resumes, transcripts, completed direct deposit forms (including cheques), copies of identity verification (i.e. driver’s licenses, first page of passports, birth certificates, etc.), injury forms, payroll correspondence, pension correspondence, benefits forms and correspondence, education credentials (i.e. certificate, degree, diploma etc.), job information history, pay-benefits history, performance evaluations, police criminal records check reports

In my previous post, I had also noted that no one knew how the information had been breached. In other words, a USB flashdisk was lost, but nobody knew when or how. That still remains the case. According to the findings, "an IT staff member pocketed it while at work but could not find it two hours later."

The breach cost $46,000 to resolve, including "staff time, overtime, supplies, postage, and other miscellaneous expenses."

USB Encryption

It's often said that USB devices that contain sensitive information should be encrypted. There's something wrong with that wording. You see, it's not that USB devices that contains sensitive data should be encrypted -- that's putting the horse before the carriage. Instead, sensitive data ought to be saved to encrypted devices. You might think it's mere verbal judo, but it's more than that.

You see, disk encryption takes some time to implement. What are the chances that someone will grab a USB disk, save sensitive data to it, and then go through the routine of deploying disk encryption on it? The answer is "nearly zero." It won't happen. The person will save the files to the flashdrive and call it a day, promising he won't take the USB device out of the office, etc. Sooner or later: data breach.

Instead, data ought to be saved to USB disks that are already protected with encryption software. This, however, poses its own problems. If an encrypted USB disk cannot be found, what are the chances that a person will go looking around for one instead of just grabbing the unsecured USB disk lying two inches to the right from the mouse?

This leads to the only sane conclusion and best practice: assume that all USB disks used at an organization that deals with sensitive data will be used to store sensitive data at some point, meaning that all USB disks should be encrypted. It's not that crazy. One company came to a similar conclusion regarding laptops the hard way.

Backup Disk Encryption: Univ. Of Victoria Data Breach

sang_lee — Tue, 24 Jan 2012 02:25:00 GMT

The University of Victoria had a data breach that left thousands exposed. While the details are not being given, it looks like an external drive was stolen during a break-in. The device was not properly secured with disk encryption software like AlertBoot, increasing the risk of identity theft for over 11,000 current and former UVic employees.

Existing Technology in Place

The site saanichnews.com quotes Stephen Neville, the director of the Centre for Advanced Security, Privacy, and Information Systems Research at UVic, who notes that the university "had the existing technology in place that should've stopped last weekend’s breach from happening."

He went on to say:

"The degree to which people may be aware of these (available) options is the issue," Neville said. "It comes down to an employee saying, 'I need to back up (this information),' as opposed to saying, 'Are there better ways of backing up the information that protects the privacy of the data?'"

You'll notice that Mr. Neville concentrates the data, never brining up "hardware" as an issue. That's because, regardless of where the data ends up, it can be easily protected using encryption software. I'm pretty sure the "existing technology" he refers to is a passing reference to encryption.

And, my, should have encryption been used. According to the details that were released, the banking information and Social Insurance Numbers for over 11,000 past and present UVic employees (beginning from January 20120) were lost in the data breach.

Saanichnews.com speculates the information was stored in an optical disk or hard drive that was locked in an office cabinet.

Encrypting Backup External Drives

Data backups are important, in more ways than one. Certainly, backups allow one to recover data in the event something happens to the original: theft, data corruption, disasters like flooding and fires, etc. But, backups are trickier than they appear because they need to be secured as well.

For example, scores of backup devices have made their way to the consumer market, in many cases external hard drives with a single, prominent button, to be pressed when you're ready to perform a backup -- literally "one-button backup solutions."

You press the button and problem solved. Right? Not quite.

Backing up the data is only the first in a chain of multiple decisions. You still have to consider other aspects, such as, where will I keep this backed up data? You don't want to keep it right next to the computer, since whatever befalls on the computer could extend to the backup as well. Think of fire, water, coffee spills, a prank gone awry, etc.

Keeping it in the same office but away from the computer also poses its own problems. As in the UVic situation, a thief could make off with the backup. And the original. And your petty cash. All at once. Or, the backup could be stolen while the original remains in place.

But, the biggest problem may come from the fact that many people will secure their originals while not extending the same security to their backup. Sometimes, this is due to a lack of education.

Take AlertBoot, for example. It's a hard disk encryption solution. Most people already have an understanding on what it does: it encrypts all the data on your hard drive. This is not wrong, but it's also not right. Yes, all the data in your hard drive ends up encrypted.

But, "encrypts all the data on your hard drive" allows certain miscues to arise. For example, most users think this means that copies of the encrypted data will also be encrypted. Like when data is backed up. But it's not, that's not how hard disk encryption works (well, not always anyhow). Under hard disk encryption, it's accurate to say that the entire hard disk is encrypted. And because the hard disk is encrypted, the data you place in it is also encrypted.

In other words, the data is encrypted as long as it's on the hard disk. Copy it to some other device that is not encrypted, and the data won't be secure anymore.

This is why AlertBoot has the option to encrypt any external media devices that are connected to an encrypted computer. It's not just meant for backups but for any instances where data is copied off of a protected device. We realize that it's the data that you're securing, so that it makes no sense to encrypt the contents of your entire computer while allowing your USB port to become a security fail point.

With something aking to AlertBoot, perhaps UVic wouldn't have had to deal with this particular data breach.

Full Disk Encryption: Assume All Portable Devices Contain Sensitive Information

sang_lee — Sat, 21 Jan 2012 02:38:00 GMT

The CEO of the Massachusetts eHealth Collaborative, Micky Tripathi, recounts the eight lessons he learned when his company was involved in a data breach when a laptop computer was stolen. It all stemmed from the fact that a laptop, which was not protected with the likes of AlertBoot hard drive encryption, was stolen.

First Hand Account - An Excellent and Insightful Read

Tripathi submitted a first-hand account of his thoughts and actions to histalkpractice.com. He starts off by noting that most might find the "details fascinating... because you realize through hard experience that protecting privacy and security is about incredible attention to the small stuff."

In keeping with that statement, he has penned a very, very long (but extremely worthwhile) article with lots of details. If you're into Cliffnotes, I'd suggest govinforsecurity.com's summary (and I'd suggest reading the original article over that).

My own concise summary (just the facts, ma'am): a laptop computer was stolen from an employee's car while the employee was having lunch. The breach affected approximately 14,314 patients (out of which approximately 1,000 had to be notified under the "significant risk of harm" clause, which is still in effect under the HITECH Interim Final Rule), and required nearly $300,000 to resolve. Security software was implemented; however, encryption software was not one of them.

As an "implementation services company" they normally wouldn't have patient data on their machines, except that they also have to deal with what Tripathi termed "kick-outs," patient information that was rejected by a system. The company, as a consultancy, helps clients figure out why the data is getting kicked out. This means patient data is transferred to their machines. The rest, as they say, is history.

Unsurprisingly, his #2 lesson learned is "assume that your portable devices contain sensitive information." This assumption is often more correct than it is wrong.

One Observation

As Tripathi has himself noted, the company wouldn't have had to deal with the situation had the computer been encrypted. Certainly, the odds of some random thief accessing his data were marginal at best, with the security software that was already used. Regardless:

And yet … the files were no longer in our control and, without encryption, were indisputably vulnerable. I’d heard the term “my knees weakened” before, but had never experienced it myself … up until that moment, that is.

Without encryption, data is indisputably vulnerable. That's why most state, federal, and international law will grant safe harbor if encryption is used -- if they do grant them. Exceptions are rarely made for other data security solutions, and when they are, they tend to be dropped later in favor of encryption.

You know what's really frustrating to me? This:

The bad news kept on coming. In April 2010, we had instituted a company-wide policy requiring encryption of any files containing patient information. If the laptop or the files had been appropriately encrypted, this theft would not have been a breach issue. Turns out that we had been shopping around for whole disk encryption options to reinforce our security policy, but regrettably we hadn’t yet implemented a solution at the time of this incident.

Cases like these, where a data breach occurs while you're considering options, are not unusual. But still reviewing options 21 months later? (The breach occurred on December 2011). Well, that's a bit unusual.

Tripathi sounds like a very smart, conscientious guy, so what gives? My guess is that he failed the way most people fail when it comes to such issues: out of sight, out of mind. He himself notes that he doesn't deal with "practice-level data" (read: protected health information), so, my guess is that he just assumed there must have been encryption in place for any employees who did deal with practice-level data on a day-to-day basis. After all, they began looking into it around April 2010. Why would someone assume encryption was not being used nearly two years after you started looking for something?

Drive Encryption Software: Kansas Department Of Aging Loses Laptop, Flash Disk

sang_lee — Fri, 20 Jan 2012 07:03:00 GMT

The Kansas Department of Aging is cautioning clients that there was a data breach of members' information. A laptop computer, flash disk, and paper files were stolen from a state employee on January 12. It's quite apparent from what's floating in the media that the appropriate laptop encryption software and flash disk encryption software were not used.

100 SSNs Lost, 7000 At-Risk

According to kwch.com, a laptop computer and other media were stolen last week from a Kansas Department of Aging employee's car. The incident impacts 100 people who were part of the Senior Care Act program, who had their Social Security numbers compromised.

An additional 7,000 seniors, including participants in the Older American Act program, were also affected. While their SSNs were not involved, other personal information was stolen, such as names, addresses, dates of birth, gender, service information, Medicaid identification numbers, and case management information. Financial information was not included.

As I noted at the top, there is no mention of how the information was secured. In this day and age, not mentioning how data was protected generally tends to mean that data security protection was not used, especially when combined with pleas to keep an eye out for "unusual activities."

Lots of Similar Breaches

This is not the first time I've come across a story where some department, agency, or division involving the elderly has been caught in a data breach. There was this one involving 21,000 Pennsylvania senior citizens, this other one in Ohio, and this one in North Carolina.

In each of the above cases, the affected numbered in the tens of thousands. The stolen devices generally were designed for portability. It doesn't take a genius to figure out that

Tens of thousands of sensitive data points + unsecured data device = bad idea

And yet, here we are, a little over four years after I've blogged my first "Aging" data breach post, rehashing the same story involving different people in a different place but under similar circumstances. How long does the insanity have to go on before something is done about it?

Laptop Encryption Software: Waterloo Region District School Board Computers Stolen

sang_lee — Fri, 20 Jan 2012 02:36:00 GMT

The Waterloo Region District School Board in Ontario, Canada has announced a data breach. It's its third breach in less than a year. The announcement, however, leaves much to be desired. They imply that something like disk encryption software was used, but don't come out and say it outright.

Look, Waterloo Region District School Board: I don't know what they've been telling you, but using encryption software like AlertBoot to protect your data is not a crime. And, its efficacy is not affected by pointing out you used it.

December 1 Break-In, 9 Laptops Stolen

According to numerous sources, the Waterloo Region District School Board (WRDB) has filed a press release stating that there was a break-in at the WRDB head office on December 1, 2011. A thief or thieves smashed a window and stole nine laptop computers used by the center's staff.

The board declined to make public what type of information was stolen or how many were affected, although they have indicated that it involves students' personal information.

Most of the coverage mentions that the laptops had "security system that would require inside knowledge to bypass" (video, swo.ctv.ca) and that "it's a layered process" (therecord.com). However, it's not really specified what this is, exactly. Both computer encryption software and password-protection fit the description of such a security system, but the latter is not considered a "security system" by professionals, whereas laypeople do consider it so. Which is a mistake. I've already noted before why password-protection is not security.

I did find one site, cambridgetimes.ca, where it's claimed that the board released a statement that "these computers use industry-standard encryption." I have yet to find corroborating sources.

What's the Hush-Hush Surrounding Encryption About?

I'm not sure what to make of cambridgetimes.ca coverage. If encryption was used, why is it not mentioned by all the other sites that have covered the story? It seems to me that pointing that "the laptops were encrypted" would be a far better description over "security system that would require inside knowledge to bypass," which is confusing because it could refer to so many things.

Could it be that cambridgetimes.ca jumped to conclusions and assumed that such a "security system" meant "encryption"? That doesn't seem to make sense, either.

But what really doesn't make sense is people's penchant for declining to mention the use of encryption. I might be biased because of who I work for, but it appears to me that the use of full computer encryption software ought to be trumpeted from the roofs by companies that use it and are subsequently involved in a data breach.

After all, break-ins, burglaries, thievery, hold-ups, carjackings, car thefts, and any number of crimes where laptops and computer equipment are stolen will not stop in the foreseeable future. In such cases, only the use of encryption guarantees* that the thieves won't access data. What could better calm down people than letting everyone know that their information is impossible to get to?

(* I must include a caveat here: assuming something stupid wasn't done, like somehow attaching the encryption password to the stolen laptop.)

AlertBoot's Stance On SOPA And PIPA: We're Against Them

tim_maliyil — Thu, 19 Jan 2012 07:48:00 GMT

SOPA and PIPA. In Spanish, one is the word for soup. The other means pipe (or refers to sunflower seeds). Pretty tame stuff. Combine them together, and you have sunflower seed soup served in a pipe.

In English, though, they're the reason why a good portion of the Internet has blacked out today in protest. SOPA is an abbreviation for "Stop Online Piracy Act" and PIPA stands for "Protect IP Act," with the IP referring to "intellectual property."

As the names imply, both of these bills have the purported goal of stopping online piracy. This, though, is not why the bills are being protested. After all, most people, including myself, are in agreement that piracy is a problem and something must be done about it, be it the illegal sale of movies or the illegal manufacture of pharmaceutical drugs. (The Motion Picture Association of America supports the bills as does Pfizer. Politicol News provides a list of the bills' supporters.)

You have your detractors, but it's my opinion that most people support copyright holders' rights.

SOPA and PIPA, though, are not the way to go, at least not in its current state. These bills are so badly legislated that its effects go beyond copyright and piracy issues. It's already been noted the chilling effects SOPA and PIPA would have on free speech, on due process, and even on international law.

In fact, the blackout has attracted so much attention and media coverage that I don't feel that I could add to the general subject.

Instead, let me illustrate how the two bills could affect a company such as AlertBoot, a managed encryption services company that is growing as an SMB and that still retains its entrepreneurial spirit.

Freezing Out Entrepreneurship

As a cloud-based encryption software provider, it's hard to believe that AlertBoot would ever fall under the auspices of SOPA and PIPA. After all, we don't provide content. And we don't link to content. We protect it.

As a cloud-based data security solution company, we are also working on offering other services that complement encryption: secure on-line backups -- because, let's face it, backups are an integral part of good data security practices -- and secure document sharing and collaboration, which is one way of ensuring that sensitive data do not fall into the wrong hands.

These up-and-coming offerings are, as I mentioned already, complementary to what we already do. They're also an outgrowth of what we already do. Had our business not revolved around using the cloud to deploy disk encryption software for laptops, desktops, external drives, etc., there's a good chance we wouldn't be exploring and building out services in this space.

What does this have to do with SOPA and PIPA? Well, for one, as a data security company, we know the value of encryption, and apply it liberally to everything we do.

We also know that a big, if not the big, reason why a client would choose to migrate to the cloud is linked to privacy: as the service provider, we've got to guarantee that no one, including us, can access our clients' data without their authorization. You could say we learned from the Dropbox controversy.

So, we encrypt everything to ensure that only authorized people can access the content in the cloud. This runs counter to SOPA and PIPA because, if the bill is passed, AlertBoot will need to police the content of our customers. And yet, we are locked out by design.

I guess one way around it is not to start the project to begin with.

Leading to a Less Secure Environment

The other solution to this legal conundrum, then, lies in not locking ourselves out. Creating a backdoor of some sort, if you will. Problems abound with such an approach.

First, what company would store its sensitive data with another that, by law, has to police the former's information? Patrolling the clouds for copyrighted content means reading through each and every file. A company like salesforce.com -- an online customer relationship management software provider -- couldn't possibly exist in its current state with SOPA and PIPA. In fact, I doubt such a company could have possibly launched to begin with: the content of customer databases are jealously guarded secrets. The mere hint that some outsider will go through one's database would be enough to kill the project.

Google's free email service stands, perhaps, as the antithesis to my argument above. After all, ads are displayed based on the content of the email you have received (in Google Apps for Business, the default setting for ads is to not serve them. This doesn't mean there isn't an engine running the background analyzing content, though), and many businesses have elected to sign up despite the implications of content monitoring.

But, many in the same position have decided not to use it due to the same implication. Plus, Google has to continuously assure its clients that no human ever reads the content of emails. My understanding is that, for as far as user privacy is concerned, there is no monitoring going on. Google wouldn't be able to make such a claim if the current SOPA and PIPA bills pass as they are. I wouldn't be surprised if there was an exodus, planned or instant, from Google Apps for Business if the bills were to pass.

Second, the problem with a backdoor is that the same backdoor that allows us to gain access to clients' content has the potential to become the vector for a data breach. As the passing year has shown, the last thing you want in your web presence is a weakness that hackers can exploit, be it those with financial misappropriation in mind or part of an online activist collective.

There were incidents like Sony's data breach, where the weakness was traced to fixes and patches that had been available for a while, meaning Sony was in the wrong, even if it was the victim. But there were also incidents where non-script kiddie hacking skills were required, such as the HB Gary breach, where traditional hacking and social engineering were the foundation of the successful data breach.

A backdoor is a very serious, potential risk no matter form it takes. It's one of the reasons why the US government was finally dissuaded from passing a law requiring crypto vendors to install backdoors into their algorithms: there was no way of knowing who would eventually exploit it. (The issue pops up during times of imminent danger, but so far, sanity has prevailed).

While SOPA and PIPA are not directly advocating a less secure computing environment, its language forces the industry to take a road towards either a less dynamic, vibrant environment or one that is inherently hazardous. This, in an era where people are clamoring for a safer computing environment.

Ripe for Abuse

Of course, such arguments are countered with the usual "legitimate sites and business need not fear. The bills target those that are actively profiting from piracy." If that's true, why not make it clear under the law? Why have it written so broadly that it's raising all this ruckus? And, what makes you a legitimate business?

Such palliative assertions are cold comfort for those who fall victim to the underbelly of legislation and political machinations. And, you can expect machinations. After all, companies abusing and bending the law for its own private goals is not news.

Heck, forget about bending the law; sometimes you they're the law unto themselves. Here's a case where Universal Music Group claims that they can take down whatever content they want from YouTube, even if it's not theirs.

Or, take as an example the link I provided earlier, about the UK student who is being extradited to the US. His offense? Creating a page that linked to pirated material (and profiting from visitors to his page on their way to some other site). I'm not about to debate the merits of the case. It's quite obvious that the student in question has a, ahem, wild streak.

I'd like to merely point out that there are many companies that essentially do the same thing and potentially link to the same sites, but their content coverage is broader that pirated content. Yes, I'm talking about search engines, the Googles, Bings, and Yahoo!s of the world. How come they're allowed to continue with business as usual while some guy is arrested? Is it because the kid didn't have his papers in order, because he hadn't registered himself as a legitimate business owner?

The fact that all of his links lead to pirated content is irrelevant. Currently, that's not a crime. Under SOPA and PIPA, it will be. One could say that he was rubbing it in the copyright holders' noses. That's not a crime, either.

In fact, I'd say that he was doing some nose-rubbing and showing copyright holders where they could find the people who were hosting pirated material. From this point of view, the kid should have been thanked for consolidating a list of sites for content owners to go after.

Obviously, SOPA and PIPA were not behind the student's arrest. These are bills, after all. But, the above stories are evidence of how broadly written laws can be abused. And there are many such stories.

AlertBoot: Against SOPA and PIPA

SOPA and PIPA place an inordinate amount of power in the hands of a minority that have shown less-than-admirable qualities from time to time, the issue of who's in the right notwithstanding.

While laws targeting piracy are needed, the current bills are -- in our view -- not the answer. Allowing SOPA and PIPA to become law as-is will be a Pyrrhic victory of sorts, unable to stem the tide of piracy while dragging down budding and growing industries along with it.

AlertBoot is against SOPA and PIPA.

If you're in agreement, visit this page and let your voice be heard.

Data Security: Why Salting Password Hashes Is Required But Has Limitations

sang_lee — Wed, 18 Jan 2012 04:51:00 GMT

The big news in the data security arena this week is, of course, the hack at zappos.com. Thankfully, data encryption software was used to protect credit card numbers at Zappos, so the fallout from the data breach is curtailed to what is generally considered "less sensitive" data (but, as more and more articles point out, the definition of what is deemed "sensitive data" is changing, and now may include what's traditionally considered "less sensitive" data).

I'm not going to rehash what's been literally covered by hundreds of news outlets. Instead, I'd like to explore passwords, hashing, and salting a bit. I've come to realize that, so far, I've been lucky when it comes to proclaiming "call to change passwords" = "no salting."

Zappos asks customers to change passwords - What is hashing?

Salted passwords elevate security... - Why password salts are necessary

...But are not the end all, be all - Compromising salted passwords

Zappos Asks Customers to Change Passwords

One of the things that Zappos required of its customers is to change their passwords. The company has also asked customers to change passwords at other sites if their Zappos password was reused elsewhere.

Normally, such a request is due to the lack of password salting during the hashing process. If you're new to the world of password security, hashing is a formula for converting text into some other text. But, it has its particularities:

One-way only. Hashing is designed to make it hard (impossible) to figure out what the original text was. For example, YouAreAUser123 could be converted to $12@f23fW2^1bsASFsd, and there's no way to convert it back. Because of this, hashing is known as a one-way function or a one-way algorithm. I've seen infographics that compare it to making sausage: once you have the end product, it's impossible to figure out which specific animal it's constituted from (yes, it's quite the disturbing analogy. But it sticks with you and illustrates the point very well).

Unpredictable. Although an algorithm is involved, meaning there's an underlying structured formula, the resulting converted text is quite unpredictable. For example, you can't figure out what the hashed result of "ha" will be based on the hashed results for "h" and "a", or "ah", or "hb", etc. This also means there will be a world of difference between YouAreAUser123 and YouAreAUser122.

Always the same. On the other hand, a particular hash algorithm will always give the same output given the same input. So, for example, if two users decide to use YouAreAUser123 as their actual passwords, their hashed values would be $12@f23fW2^1bsASFsd, using the example from the first bullet above.

That last point is why the theft of unsalted passwords results in companies strongly suggesting that users change their account passwords everywhere: since the hashing algorithm is not kept secret, and it will always end in the same result, hackers could take a list of words, hash them, and compare their own results with the hashed passwords they've stolen.

If they see a match, they can look up the unhashed password in their original list. This is the concept behind rainbow tables, a table of pre-computed hash results.

What about salted passwords, though?

Salted Passwords Elevate Security...

Salting is the process of adding extra characters to the password. Because the presence of one extra character -- or changing one character (as in the YouAreAUser123 v. YouAreAUser122 example I've given) -- results in completely different hashed results, it means hackers will have a harder time figuring out the original non-hashed password.

For example, let's say that the salt is "a", added to the beginning of each password. In that case, the user submits his password as YouAreAUser123. The actual password ends up being aYouAreAUser123 and this is hashed for a completely different outcome. The user keeps using his original password, of course. The salting is done by the company's servers.

When hackers breach this particular password database, they won't be able to use a pre-configured table to look up the original passwords because the hashes will not match up at all. If salting is used to secure passwords, then, conceivably, users don't need to change their passwords because of a data breach.

However, this only works as long as the salt is kept secure. If the salt is also exposed, it's short shrift for a hacker to attach the salt and generate a list of hashed passwords.

Certainly, the hacker will have to wait for the passwords to be generated; however, it's the computer doing the heavy lifting. After the initial setup, a hacker can just sit back and relax.

...But are Not The End All, Be All

But, there's still a way to figure out passwords even if the salt is NOT compromised. It hadn't occurred to me sooner because it's success has been eliminated to a large degree in the world of encryption software, but salted passwords can be compromised via frequency analysis.

Frequency analysis involves seeing how often something pops up, making an educated guess, testing it, and generally trying to solve a puzzle. For example, with certain early encryption systems, one could guess the underlying message because "e" is the most recurring letter in the English language, followed by "t" and "a," respectively. So, if "z" shows up the most in an encrypted text, followed by "b" and "a," then "z = e", "b = t", and "a = a". It's not always as straight forward as that, but it worked, generally.

The same can be done with hashed passwords because people don't use secure passwords. Time and time again have we seen people using passwords such as "password1", "iloveyou", "trustno1", and others that regularly show up on hacked password lists.

So, a hacker can compile the frequency of particular hashes showing up; list the top 20 or so; and guess via trial and error as to which hash might correspond to which password (the presence of salt doesn't matter). In Zappos's case, it's implied that 24 million passwords were compromised, so after a little testing, hackers should have figured out the passwords of (possibly) tens of thousands of people.

So, even if Zappos had salted their passwords, it stands to reason it would recommend that customers change their passwords.

One could, of course, use variable salts...but this detracts from the real issue: using strong, secure passwords. If everyone were to use complex passwords, the need for salting would not exist (in theory, at least).

Related Articles and Sites:
http://en.wikipedia.org/wiki/Cryptographic_hash_function

Data Encryption Software: Yet Another Article on Yet Another Authentication Scheme

sang_lee — Tue, 17 Jan 2012 03:08:00 GMT

Or, YAA On YAAS. The site msnbc.com is carrying another article on futuristic password killer initiatives by the military. Passwords are, of course, of great interest to those dealing with data encryption (such as yours truly, at AlertBoot) since they're usually the points of failure when it comes to information security.

And, yet, one wonders whether passwords can really be killed. It appears to me that it's not a matter of developing "better" ways of authenticating people.

Same Old Story, New Solutions, Same Old Results

As msnbc.com notes, "today's world requires countless passwords," and goes on to note that

the U.S. military wants to eliminate clunky passwords by creating a security system that actively recognizes individuals based on computer keystrokes, language patterns or even typing speed....focus[ing] on the behavior of each individual reflects an interest in each person's "cognitive fingerprint" left behind by how the mind processes information.

There is nothing new about such initiatives. In my brief time at AlertBoot, I've covered:

Your sitting profile as a password

Fingerprints, fingerprints, and more fingerprints

Facial recognition

Typing speed

I'm probably missing quite a number of other developments that have been floated and shelved over the years. It doesn't matter what form it takes, it's always those passwords that end up being used by most organizations when it comes to authenticating people, sometimes exclusively.

Even with solutions that offer something other than passwords for authentication (including encryption software, which provides physical tokens for identification), passwords are always there, either as part of a two-factor authentication scheme or as a backup in case the user loses the token.

Passwords are Problematic

Passwords, though, pose many problems.

First, passwords can be weak. As forbes.com notes in this article, users don't necessarily choose strong passwords to begin with.

Second, passwords can be shared. When something can be so easily shared, it's problematic as an authentication scheme. Plus, it cannot be easily "unshared." For example, if the CEO gives her secretary the password to her computer because of an emergency, how do you wipe it from the secretary's brain after the one time? You can't, the password has to be changed. (Anyone manufacture those MIB neuralyzers, yet?)

Third, passwords can be hard to memorize. An issue that is meant to counter the first point, administrators can force users to create password that are too complex to memorize. This is not a problem per se, but leads to....

Fourth, password resets can be expensive or be another point of weakness. Resetting passwords is, despite its simplicity, kind of expensive. One can't just reset a password for anyone -- you've got to be able to determine that people are who they claim to be. This involves expenditures, such as hiring people or services for the express purpose of helping people with their password issues, or using self-service password resets that pose its own problems.

Microsoft recently published a paper on the "resilience of passwords," and how, despite professionals having predicted its demise for decades, it's still going strong -- and will do so for the foreseeable future.

The Power of Free?

A number of words popped out at me during a brief and quick skim of the Microsoft paper: "Mis-aligned incentives can cause desirable solutions to fail." I'll go over the paper this week, but it seems to me that this is probably one of the main reasons why passwords have prevailed despite their shortcomings.

Think about it. Passwords aren't a physical entity, so:

It costs nothing to generate them

There are no transportation/delivery costs

Sending and generating a replacement costs much less than physical delivery

Users can't "forget" to bring it

I realize #3 and #4 above appear contradictory to what I wrote before. Think of it in the following manner:

For #3, if an organization decides to go with the "butt verification" system, passwords are never sent anywhere. One assumes that telecommuting is not really an option: you'll have to move your buns to where the computers are. No passwords to lose, no passwords to generate. The costs associated with the loss of passwords are nil.

However, if some other method of verification is used over passwords, such as tokens, then the costs associated with replacing them are formidable over those of generating and delivering a new password. Both require that one somehow confirm that the intended are the recipients, but password generation doesn't involve physical delivery. So, there are options that can be cheaper or dearer than replacing passwords.

For #4, a user could forget a password, just like one can forget their tokens back at home. But, this reflects the limitation of the English language. A token can be "forgotten" in various ways: it can be forgotten (left behind at home), it can be misplaced (don't know where I left it, although I'm sure it's at home), or it can be stolen by force.

Passwords can be forgotten, but can't be misplaced. They can be stolen, but so can tokens. In a sense, passwords have a leg up on tokens.

Anyhow, this post is not meant to be an all-comprehensive monograph on the subject. I'm just trying to point is that, as long as passwords remain the cheapest alternative -- in monetary terms -- they're going to be around for a very long time.

Drive Encryption: Data Lost In Transit Is Now #2 Reason For Data Breaches

sang_lee — Fri, 13 Jan 2012 02:05:00 GMT

According to the Identity Theft Resource Center, hacking is now the leading cause of data breaches followed by data lost in transit (laptops, external storage devices, USB flash disks, etc) and insider theft (#2 and #3, respectively). All the more reason why encryption software should be used.

419 Publically Disclosed Breaches in 2011

According to informationweek.com, the Identity Theft Resource Center (ITRC) compiled the numbers of all 419 publically disclosed breaches in 2011 and found that the number one reason for a data breach was hacking (26% of all incidents) followed by "data on the move" (18%) and insider theft (13%).

While the report hasn't been released yet (informationweek.com got an advance copy), I think the report could be slightly contentious based on one passage:

Last year, data breaches triggered by hacking--defined by the ITRC as "a targeted intrusion into a data network," including card-skimming attacks--were at an all-time high, and responsible for 26% of all known data breach incidents. [my emphasis]

I'd still have to wait for the report to see the details, but I'm left wondering if card-skimming is really hacking. It certainly fulfills the condition of being "a targeted intrusion into a data network" since ATMs are the public-facing endpoints of a network (banking, that is). And it certainly is hacking, in the most traditional sense.

And yet, it just doesn't feel like it should be lumped in there with the likes of the Sony data breach, which I'm sure is included in that category (biggest hacking incident in 2011).

For one, the data was breached prior to it being entered into a network, or as it was being entered into a network. That is, it's not a case where the hackers obtained customer information because a company had weak security in place. Plus, it doesn't even have to occur at the ATM. For example, a rogue restaurant waiter network that uses tiny all-in-one card readers (such as in this demonstration) can easily cause a massive breach).

On the other hand, a data breach is a data breach no matter how, where, and when it happened, or whose lack of security awareness was being exploited.

Why is This a Problem?

Why does this matter? News organizations are bound to run with the headline, since it's the first time hacking is #1. Since people in general don't read the nitty-gritty details, people might make the unfortunate assumption that they should invest in hacking prevention solutions at the expense of other areas, such as using encryption software on laptop computers.
The thing is, the difference between 26% and 18% is not so vast that companies ought to be considering investing more in one area over another. I can't blame ITRC for compiling its results in the manner it has, though. Their focus is on providing "victim and consumer support as well as public education." So, it makes sense for them to lump certain categories together, and guide the conversation as to what people should be looking out for, in order to protect themselves.

I'll follow up to see if my concerns are unfounded in a future post.

Related Articles and Sites:
http://www.informationweek.com/news/security/attacks/232400252

Drive Encryption Software: 1/5 Of Breaches Occur By 3rd Party Recovery Services

sang_lee — Thu, 12 Jan 2012 04:55:00 GMT

According to a number of sites covering the issue, the Ponemon Institute has released a survey showing that 21% of information security breaches occur when corporate data is being held by a data recovery service provider. This is one of those areas where disk encryption software cannot help because, well, one's voluntary allowed a third party to access the data.

I mean, how else is one supposed to recover data?

769 IT Practitioners Surveyed

Ponemon surveyed 769 CIOs and CISOs, and of the 87% who responded as having experienced a breach in the past couple of years, 21% said a breach occurred "when a drive was in the possession of a third-party data recovery service provider."

Disk encryption was created for those instances where a third party has your device: namely, when it's stolen (yeah, most people wouldn't quite call thieves a "third party." But if fits the definition). However, in this case, the third party is doing something on behalf of the data owner. And, generally, a third party like a data recovery service provider requires access to the hard disk.

Otherwise, how's the service going to know if it's actually doings its job correctly or merely worsening the problem?

In such situations, the only solution is to use a data recovery service provider that's been vetted. As inforworld.com points out, though, this is not always possible: what if an employee's computer breaks down while on the road?

Plus, even if a company is vetted, it doesn't necessarily mean that the employees will act faithfully according to the company's policies. For example, I remember reading how the geeks at Geek Squad would copy content from computers that came in for servicing. This certainly is not company policy.

Perhaps I'm jumping the gun here, though, as most companies are not particularly interested in security:

About 81 percent of the respondents said the speed of recovery was the most important factor in choosing a vendor and 75 percent said the ability to successfully recover data was the most important. Security-related concerns were not a priority for these respondents, according to the survey. [eweek.com]

Seeing how 18% of data breaches can be traced back to a data recovery vendor, perhaps the placement of data security in the vendor factor totem pole ought to be thought over.

Data Encryption: Victorinox Offering $3000, 1 TB Flash Drive Later This Year

sang_lee — Thu, 12 Jan 2012 02:09:00 GMT

According to various sites focusing on gadgets, Victorniox -- manufacturers of the official Swiss Army Knife -- has debuted a one terabyte flash drive that will cost $3,000 (or less, the company hopes). 1 TB is a lot of information. No wonder, then, that it will feature AES-256 encryption, which is the algorithm powering AlertBoot laptop encryption software.

New, Not Unprecedented

This is not the first time that the knife company (and now, apparently a lifestyle company offering knives, cutlery, timepieces, travel gear, fashion accessories, and fragranges. However you might want to transform yourself, to me, you'll always be the unofficial sponsor of MacGyver) has offered an attractively-packaged USB flashdrive. Nearly two years ago, Victorinox offered a similar product.

Then, like now, the flashdrives were protected with strong encryption software. And why not? It only makes sense to offer good security for a device that is (a) very small, making it probably to lose it and (b) attractive.

The device comes in gigabyte (64, 128, 256) and terabyte (1) flavors and will feature an LCD display that shows storage availability.

Encryption Software Not Just for Small Stuff

Of course, I'm not implying that encryption should be available (and used) because the device is small. Encryption should be seriously considered for any devices that (a) can be lifted by the average person and (b) store sensitive information.

Under these conditions, cryptographic protection should be used on external hard disk drives, USB flash drives, laptops, and other mobile devices (like an iPhone), but also on backup tapes, desktop computers, CDs, etc.

If you need encryption, there are plenty of good, free solutions out there. If you need something that doesn't require you to do everything -- ranging from installation to encryption key backups -- then options like AlertBoot endpoint security are available.

Hard Disk Encryption Software: Computer Repairman Steals School Computers

sang_lee — Thu, 12 Jan 2012 00:21:00 GMT

Encryption software for desktop computers is not a bad idea at all, as the following story shows. According to kxan.com, a man posing as a computer repairman walked into two schools in Austin, Texas and walked out with five computers.

Assumed He was Legitimate

Two Texas schools were defrauded of their computers in November 2011. A man showed up at a school, walked into a classroom, and told teachers that he was to pick up computers for repair. Most of the teachers assumed he was legit. The man made off with two computers. He repeated the same one week later at another school, netting three more computers and a projector.

A review of security camera footage and subsequent campus-wide alerts led to staff recognizing him as a contracted computer technician who had previously worked with the schools. He is still at large, although computers were retrieved from pawn shops.

The story reminds me of the Khaki Bandit, a man who'd dress up in corporate uniform, walk in to the offices with a bunch of employees, "work late" until there was no one around, and then steal laptops. Sure, the M.O. is different, but not how the crimes were perpetrated.

Computer Encryption Software Protects Data Against Theft

The fact that a computer is a desktop computer is no guarantee that it won't be stolen. In fact, it appears that, in the above case, desktop computers were targeted on purpose.

While I doubt that sensitive personal information was stored on these computers (after all, they were computers used in the classroom), it highlights the importance and usefulness of computer disk encryption protection. With encryption the data is kept safe from the thief's eyes, no matter how a computer is stolen from a location: break-ins, impersonation, muggings, etc.

Disk Encryption Software: Brighton and Sussex NHS Facing Largest Fine To Date (Updated)

sang_lee — Wed, 11 Jan 2012 02:50:00 GMT

Brighton and Sussex University Hospitals NHS is facing a fine of £375,000 fine for breaching the UK's Data Protection Act (DPA). Confidential information on tens of thousands of people were exposed when decommissioned hard drives were stolen. Like I've often noted, hard disk encryption like AlertBoot is not just laptops and external hard drives only. Full desktop encryption is a good idea as well.

Update (12 JAN 2012): phiprivacy.net notes that the thief actually worked for Sussex Health Informatics Service, the company in charge of disposing of the hard drives. This makes it an internal attack, which is one of the hardest types of data breaches to avoid. And yet, this is the breach that has garnered the dubious honor of receiving the highest ICO penalty to date. I can only assume that I've overlooked something. Issuing some kind of penalty is warranted. Like I noted in my conclusion, the use of encryption would have prevented the situation from ever developing into a data breach. But, the largest penalty to date?

Largest Fine to Date

Brighton and Sussex University Hospitals NHS is facing the largest penalty the Information Commissioner's Office has assessed to date. The trust will contest the fine, noting that they were the victims of a crime. To which I would remark, being victimized doesn't absolve one from his responsibilities.

One of the surprising things about this story is that the ICO is assessing a fine that has no precedence or structure. Supposedly, the ICO doles out its penalties based on what kind of message it's trying to send. According to theargus.co.uk, "tens of thousands" of people were affected by this breach.

And yet, when A4e lost a laptop and affected 24,000 people, it only got fined £60,000.

I don't understand how having been a victim of a crime merits a larger penalty than being cavalier with sensitive data (in the A4e case, the laptop was stolen from an employee's house. It might not be as bad as leaving it at a McDonald's or a car break-in, but come on. You're allowing an employee to go about with sensitive data and haven't encrypted it? That's being careless).

One could argue that holding a massive number of drives merits extra security. But, ultimately, the severity of a data breach lies not in the number of hardware involved, but the number of people affected by a breach. I guess you could also raise fines because people are not paying attention, so you need to send a stronger message: the A4e fine was handed in November 2010. If Brighton and Sussex didn't do anything in the past year...well, the original message didn't take, did it?

HDDs Taken from Locked Storage

The hard drives were, according to theargus.co.uk, stored "in a locked store at Brighton General Hospital where they were being decommissioned." One thousand (1,000) hard drives were decommissioned. It's safe to assume, I'd say, that some, if not most, of the hard drives were used in desktop computers.

The decommissioned drives were to be disposed by Sussex Health Informatics Service. They didn't do a good job, apparently, because four of them ended up for sale on eBay. A subsequent investigation showed that a total of 232 drives were stolen (all were eventually recovered)

Disposed. It's a tricky word. Technically, hard drives could be disposed of and still show up on auction sites. After all, disposed doesn't necessarily mean "destroyed," which is what one generally does with sensitive data, and why destroy equipment that still works if you can sell it and recoup some of your sunk-in costs?

Encryption Software for End-of-Life and Resale

When reselling equipment that used to store sensitive data, it should be ensured that it's done correctly... and by "correctly" I don't mean ensuring one's not scammed out of his money after the sale. Rather, I'm referring to selling the hard drives while sensitive information is still technically available on them.

Of course, you don't want to sell hard drives that visually contain sensitive documents in them. However, you also don't want to sell hard drives where files can be retrieved (resuscitated, if you will). When it comes to computers, you can (a) "delete" files or you can (b) write over them.

The former, a misnomer, doesn't really delete the file; it merely marks the bytes where the document was stored as "free to use," meaning eventually it will get written over with new files: word processing files, spreadsheets, images, what have you. However, when it will be written over is up to the computer. Conceivably, the "deleted" file could still be reclaimed 5 years after the fact.

The latter, "write over them", is what computer technicians and data privacy laws mean when referring to "deleting data." Data in a computer is only truly erased when a computer's storage sector is written over (replaced) with new data.

That's why full disk encryption is valuable when it comes to data security. With the use of encryption, data is stored in a garbled state. By using a password or other means of access, that garbled information is "made normal" temporarily, so you can work with it. When the computer is shut off, the data reverts to its garbled state.

If Brighton and Sussex University Hospitals NHS had used encryption software to protect its computers' hard drives, it wouldn't be in its current position. Patient data would have been protected during the lifetime of the computer as well as afterwards, when it was marked for disposal (pulling the disk drive from computers wouldn't have affected the encryption state).