AlertBoot Endpoint Security Blog

Cost Of A Data Breach: State of Utah Fires Tech Director Over Medicaid Breach

sang_lee — Thu, 17 May 2012 00:19:00 GMT

In a move to restore public trust after 780,000 people were involved in a data breach, the governor of Utah has fired the state's top IT guy. I cannot recall any other instance where someone who was not directly involved in a data breach was fired for being remiss in his duties. I also hear that something akin to drive encryption software like AlertBoot will be used to secure data on servers.

Biggest Utah Data Breach to Date - A Summary

A summary of what happened, since I haven't previously covered the Utah Medicaid data breach:

According to fox13now.com, on March 10, hackers attached the Utah Department of Health servers. On March 30, the hackers started downloading data -- which ultimately included names, addresses, and SSNs for 780,000 Utahns -- and the government's IT department caught on to it on April 2.

On April 4, the government announced the data breach, claiming that 24,000 people ("claims") were affected.

On April 6, the figures were revised the figure to 181,604 people (with 25,096 having their SSNs affected). It was explained that the initial 24,000 claims did not correspond to people, but to files, which could contain claims on hundreds of people.

On April 9, the figure was revised to 780,000 people, with 280,000 having SSNs stolen and 500,000 people having less sensitive data stolen.

Notably, the April 9 notice from the state remarks that (my emphasis),

The data breach initially occurred on Friday, March 30. A configuration error occurred at the password authentication level, allowing the hacker to circumvent DTS’s security system. DTS has processes in place to ensure the state’s data is secure, but this particular server was not configured according to normal procedure. DTS has identified where the breakdown occurred and has implemented new processes to ensure this type of breach will not happen again.

Later, it was revealed that the so-called configuration error was a weak password. Actually, it was more than a weak password: it was the default password.

Director of the Department of Technology Services Asked to Resign

Due to the public outcry over the data breach, the Governor was forced to make a number of decisions, including firing Utah's head IT guy. He also announced hiring a public relations firm to manage the crisis, and also promised that information would now be protected with encryption when at rest in servers, in addition to when the data is in transit.

Other interesting facts:

The state has engaged a contractor to conduct an independent security audit of the state’s information technology systems. There also is a contract to monitor efforts to contact and notify victims. Together, those jobs are estimated to cost about $1.3 million. [sltrib.com, my emphasis]

So, it looks like Utah's data breach will cost at least $1.3 million, plus whatever is spent on first-class mail and the cost of offering free credit monitoring to 780,000 people (the take up rate is usually in the single digits to the mid-teens, but there have been cases where nearly 33% of people take up the offer. Of course, all of this comes out of the taxpayer's pockets.

And, it was revealed that the breach was bigger than it was supposed to because the state kept information around for too long (my emphases):

Medical clinics used the server to validate claims of retirees on Medicaid and others. The stolen information included birth dates, addresses, and in some cases, Social Security numbers... State officials have said the information should have been deleted from the server once a claim was validated, and should not have been retained as records. [businessweek.com]

You Can't Be 100% Safe, But This is Ridiculous

Data breaches will happen; you can never be one-hundred percent safe from a data breach. It's a fact of life, like death. But, there are breaches and there are breaches. To find that the root reason for a data breach is someone in the IT department foregoing the process of changing the default password is....dumbfounding, to say the least.

I'm not sure if I can agree to the IT honcho getting fired (I have mixed feelings, and this looks more like a policitical move than anything), but someone definitely ought to be. But, if you're firing the head IT guy, you might as well fire the guy who actually caused the breach in the first place. Otherwise, it'd be like firing the CEO of a taxi company because someone was run over by a company cab, but keeping around the actual cab driver who ran over the poor victim. Actually, make that a drunk cab driver because that's how stupidly irresponsible it is not to change the default password to a server connected to the internet.

The linchpin that allows encryption software to do what it does best -- protect data -- is, realistically, the password. Certainly, the encryption algorithm's robustness is important, but generally the weak link in the chain tends to be people choosing their passwords. As such, we know over here at AlertBoot the importance of preventing people from using weak passwords by providing administrators a way to set up password policies. There's an entire industry built around password security.

And here you have a situation where nearly one-third of Utah's residents were affected because some guy forgot to change a password from what I imagine was "12345" or "administrator" to something more acceptable. And, the magnitude of the insanity was covered by wrapping the details under the cover of a euphemism, "configuration error."

Gee, anyone wonder why the people in Utah are so angry? It's one thing to experience a data breach because "it happens to everyone" and something else to find that you were affected because your data custodians were essentially "asking" for a data breach.

Data Breaches: S.Carolina Took 9 Months To Notify Breach Victims

sang_lee — Wed, 16 May 2012 00:04:00 GMT

Nearly 17,000 affected by a data breach in York County, South Carolina were not contacted until nine months after the event took place. South Carolina is one of the forty-odd states that have a breach notification law (and is part of a subset that includes safe harbor provisions from notification when digital data encryption like AlertBoot is used).

I briefly looked into South Carolina's data breach notification law back in 2009.

Couldn't Figure Out If Information was Accessed

One of the key tenets of South Carolina's data breach notification law is that those affected are to be alerted of the breach in "most expedient time possible and without unreasonable delay," as pointed out in infosecurity-magazine.com. Nine months is anything but.

The excuse given for this massive delay:

County officials said that they took so long to notify potential victims because their investigation found no indication that the information was taken from the server. Forensic testing of the server revealed "no smoking gun", Joel Abernathy, director for Your County's IT department, told the newspaper. [infosecurity-magazine.com]

But, this does not mean that they weren't aware that a hacker or hackers were roaming inside their digital network: the county was concerned enough to order a shutdown of the database.

Badly Written Laws Lead to Bad Results

Two years ago, I had applauded the introduction of data breach notification laws by states. Today, there are only four states that are holding out on passing such laws. The federal government has also passed or strengthened laws, although they are specific to industries (such as the HITECH Act that strengthens HIPAA).

The results from the legislative efforts are making one thing abundantly clear: data breach notification laws do have their intended effect. It sounds obvious in hindsight, but when they were being passed, plenty of cynics wondered whether it'd be legislation that would end up being ignored (like the Ohio law that makes it illegal to get fish drunk).

Also clear: badly written laws lead to bad results, like in the above case. For example, how do you define "most expedient time possible and without unreasonable delay"? Two days from when the breach is discovered? Two weeks? Two months? Or is it two months since the breach itself? Open-ended laws and definitions lead to ludicrous situations.

Compare the above to HITECH's Breach Notification Rule. It also features the "most expedient time possible and without unreasonable delay" passage. However, an upper limit is set, noting that notifications have to be sent out within 60 calendar days, no ifs or buts.

It's time for states to take a look at their current laws and see if they fall short in any areas. Updating a law only three years after it was passed might seem a little too soon, but let us not forget that three years is a lifetime for the underlying currents that have led to such laws to be passed.

Data Encryption Software: California Home Care Workers Data Missing

sang_lee — Tue, 15 May 2012 01:50:00 GMT

The state of California has had a data breach that involves more than 700,000 people. According to various news outlets, payroll data that was used in the state's In-Home Supportive Services program was lost while being transported. Of course, since the breach is being made public, we can infer that data encryption was not used to secure the data. But then, how to you encrypt a microfiche?

Oh, Those Halcyon Days

It's funny how people want it both ways. When a disk or a laptop goes missing or is stolen, people get busy criticizing the fact that data was on a laptop:

"What was sensitive data on 50,000 people doing on a laptop?"

"The move towards digital records only means more information security breaches"

Etc.

But, here comes along a case where the data is not stored digitally and all of a sudden it's,

"It's hard for us to believe that in one of the largest states in the union, we're using such an antiquated system," said Steve Mehlman, a spokesman for a labor union representing 65,000 home care workers. "It clearly needs to be modified."[latimes.com]

and,

Michael Cox, a spokesman for Service Employees International Union, which represents 300,000 home care workers, said the fact that such "primitive security measures are still in place is inexplicable." [latimes.com]

Granted, it's different people making taking opposing views at different times, under different circumstances (well, the above two are making the same argument, but I'm referring to all the discussions taking place over a temporal continuum).

But, as a whole, it's just insane. There are precious little instances in life where you can have your cake and eat it, too. You can't argue for and against data being stored on paper and electric form. It would preclude society from storing any data at all.

Digital Data is Easier to Secure, Provides Better Protection

The truth is that digital data is easier to protect than any paper document or microfiche, or whatever other old-world technology you're looking to use. The reason? Data cryptography.

The use of AES-256 full disk encryption on laptops means that the information stored on that device is, for all intents and purposes, inaccessible -- it would take billions of years to crack it.

The argument can be made that encryption has its weaknesses: people sharing passwords, people taping passwords to their laptops, using weak passwords, etc. These are not weaknesses with digital data security, though. It's people's behavior, behavior that leads to breaches no matter what the data storage medium happens to be.

For example, take the microfiche case above. It could be argued that the reason for the data breach is tied to not enough tape being used to secure the box in which the microfiche was being delivered. Someone got lazy, decided to cut corners.

Other such behavior: paper documents with sensitive data left on desks; people not bothering to lock documents in a file cabinet (or not bothering to lock the file cabinet itself); not securing doors and windows; taking sensitive documents home; etc.

The issue, then, is not whether someone is carrying the information of 50,000 people on a laptop computer. The issue is why people are walking around with information that hasn't been successfully protected with the likes of Alertboot endpoint encryption.

Data Encryption: Belgian Bank Receives "Idiot Tax" (aka, Hackers Blackmail It)

sang_lee — Mon, 14 May 2012 23:01:00 GMT

Earlier this month, hackers threatened to release a bank's information if the financial institution didn't pay them €150,000 (approximately US$197,000). While it sounds like blackmail, the hackers deemed it an "'idiot tax' for leaving confidential data unprotected on a Web server." It turns out, the information was stored unencrypted. Online. Data encryption software, like AlertBoot, is mature technology. It's importance is known by professionals and laymen alike. And, we know hackers exist. So, why the half-brained move?

Elantis/Dexia Stored Unsecured Data

The Belgian credit provider, Elantis (owned by Belfius Bank, formerly known as Dexia), was given until Friday, May 4, 2012 to give in to the ransom demands. The firm announced that it would not do so. Instead, Elantis took its site offline and contacted the Belgian Federal High Tech Crime Unit, which is investigating the attack.

So far, nothing has happened. No one was arrested, which is not surprising, but the customers' data have not been made public either. What does this mean? Perhaps it's a sign that the hackers got cowed by the bank's response; or that the hackers are waiting before making their move; or that the threat was not a serious one to begin with.

As data breaches go, it's not a very big one. The bank is assuming that the hackers captured information for 3,700 customers. A spokesperson noted that it could affect existing and potential customers, and that "we [the company] don't like blackmail."

Well, that last part goes without saying.

Another that thing that also goes without saying: you should be storing sensitive client data in encrypted form, be it online or on a medium perceived as being slightly safer, such as your laptop computer.

I must say that I'm surprised that a European bank is involved in this case. Not that European banks haven't been in the news over data attacks. However, when you consider that banks generally tend to be security conscious -- they're one of the biggest users of advance data protection technologies -- and that Europe has some of the strictest data security laws in the world, it's hard to understand where Elantis got the gall to save customer data in an unsecured form.

One could argue that it could have been an oversight. It happens to the best of us. But, that's not true. It would have been two oversights: (1) not using encryption software [] where it was necessary (security is supposed to be multi-layered) and (2) allowing hackers in via whatever method they used. If the company had been remiss in only one of the two, there wouldn't have been a data breach.

Mobile Security: BlackBerry Password Off-Limits To Authorities

sang_lee — Sat, 12 May 2012 00:14:00 GMT

A man who was arrested for transporting 364 pounds of marijuana packed in 15 bundles in his tractor-trailer rig cannot be forced to reveal his password, according to a judgment. The case confirms two things: (1) encryption on mobile devices like AlertBoot is a pretty good deterrent against data snoops -- be they the government or criminals with a penchant for ID theft, and (2) revealing your password to encrypted data can only be done under the "foregone conclusion" doctrine.

Prosecution Asks for Court Order to Force Password

According to dailyrecord.com, the judge noted that forcing the defendant, J. Arturo Vergara, to provide the password would go counter against his Fifth Amendment rights. The prosecution argued that disclosing a password "doesn't reveal any information."

Which is a very poor argument to make for a number of reasons.

First, nobody really believes it.

Second, cases involving encrypted data have generally not revolved around revealing passwords but asking for an "unencrypted copy" of the data; arguably, the password remains a secret. I imagine that this is because the law is still murky on whether a password is like a physical key to a lock box or a combination (think high school locker) to a lock box (a person can be forced to provide the former, but providing the latter is considered a trampling of the right from self-incrimination).

Third, and this is actually tied to the second point above, if you can provide the password to an encrypted device, then the prosecution can make the argument that the device belongs to the defendant, and any information, incriminating or otherwise, also belongs to the defendant. Simply having a device on your person is grounds for suspicion; being able to access its data could be a nail in the coffin.

Think of it this way: having a bloody knife on you is one thing; having a bloody knife on your person as well as a hit list with a promise to pay $20,000, and the corresponding money on you, is something else. Providing a password to an encrypted device, then, could be the linchpin on which everything is revealed.

Earlier Cases Already Filtering Down to Lower Courts?

This latest development is in keeping with previous cases involving encryption and passwords, except those cases all revolved around laptops, whereas this latest case is the first that I know of that involves a mobile device.

There are at least three cases that are instructive in the matter of revealing encrypted material and the government: Fricosu, Boucher, and John Doe. Of the three, only the last one conclusively ruled that revealing a password to encrypted data was against a defendant's Fifth Amendment rights, whereas the first two ruled the opposite, that revealing the password to encrypted content (or providing an unencrypted version of the data) is quite legal.

What appears to be an inconsistency on the application of the law is actually anything but: all of them revolve around the Fifth Amendment's foregone conclusion doctrine.

In other words, is this a fishing expedition or an "I know what's there, let me dig and uncover it" expedition? Or put another way, the question is whether the government can prove that it knows what's in the encrypted data. If it can, forcing a defendant to reveal the encrypted data is not against one's rights because said content falls under the foregone conclusion doctrine.

In Boucher and Fricosu, the government had evidence that incriminating information exited in the encrypted data. In John Doe, the government had no clue; all they knew for certain was that there was a lot of encrypted data, period. So, the ruling in the first two is that a password or unencrypted data must be provided; in the John Doe case, the password cannot be forced out of the defendant.

Coming back to our trucker, the prosecution could not prove that they knew incriminating evidence existed in the trucker's mobile device (dailyrecord.com):

The judge noted that, under certain circumstances, a person could be required to give up a password or decrypt a computer hard-drive for police. But those circumstances involve proof that the device absolutely belongs to the suspect and independent information that makes it a "foregone conclusion" that evidence will be found on the device.

Troiano said police have established the phone belongs to Vergara and have some evidence through the memory card that the BlackBerry was used in planning the marijuana transport.

But the judge rebutted: "In this case, you only have speculation."

Laptop Drive Encryption Software: Thieves Literally Snatch A Laptop Computer From User's Hands At A Starbucks

sang_lee — Fri, 11 May 2012 22:45:00 GMT

Three men in Phoenix, Arizona have been arrested for stealing laptops from coffee shops. I've read of a handful incidences over the years where people steal laptops from their owners at coffee shops; those, however, generally tend to be acts of stupidity, with the thieves trying to get away on foot. In this case, it was inarguably premeditated.

Of course, the theft of laptop computers from coffee houses is nothing new, and the need for hard disk encryption like AlertBoot, if working out of a coffee shop, is old news.

Getaway Car Readied

According to kpho.com, this is how the crime went down on their last caper: three men drove around town and visited a number of coffee houses. They went through the parking lot of an establishment several times. Two of the men stepped out of the car and went into the coffee house, the third remaining behind in the car -- no doubt, with the engine running.

Of the two men who left the car, one opened the door and the other went in and "unplugged and snatched" the laptop -- while the owner was typing on it! The two jumped into the car and the group drove off.

Was Disk Encryption Used?

Was it? Does it really matter? The getaway car was under police surveillance, so the owner of the laptop got his device back shortly. However, not everyone can count on such luck for the return of their stolen laptops -- and more importantly, their data. The only reason police were put on the trio's tail is because there were a string of similar thefts. Previous victims haven't, as far as I know, received their laptops back.

So, yeah, the question of whether encryption software was used does matter. I don't know the answer to this question, but I can kind of guess what went on in the owner's mind.

For some reason, we tend to think that our devices are safe if they are within our reach (such as right under our noses). Generally, we are right. But, the occasional evidence to the contrary shows how tenuous that belief is.

Data Security And Privacy: FTC Gets MySpace For Overpromising Privacy

sang_lee — Fri, 11 May 2012 01:48:00 GMT

The Federal Trade Commission has gotten another high-profile company to settle to charges of making promises they did not keep. According to various sources, MySpace, yesteryear's Facebook, has agreed to settle with the FTC because it "misrepresented its protection of users' personal information." This particular settlement is different from the previous ones I've covered because it's not really about protecting sensitive data (such as with tools like full disk encryption from AlertBoot).

Rather, MySpace was caught providing third parties with its service's users' information when it promised not to do so.

An FTC Pattern

This is not the first time that the Federal Trade Commission has brought charges against companies for not providing adequate security. In 2010, it had brought charges against RiteAid because the company had disposed of documents without destroying them, despite a promise to protect patient information on their website.

In 2011, Twitter settled with the FTC over charges of inadequate security. Again, the company had made the promise (in its EULA, no doubt), that it would promise to protect client data.

Earlier this year (just a month ago, in fact), charges against RockYou were settled, although I found it a bit odd because the FTC got them on a COPAA violation, but the investigation into the company was started because of its massive 2009 data breach that involved 32 million usernames, passwords, and email addresses (at least, that's my understanding).

The message is quite obvious: if you make a promise to consumers about protecting their data, you've got to live up to that promise.

Not Living Up to Promises

Well, it turns out that the FTC is not only concerned over companies being lax in protecting information from potential outside threats. They're also concerned about privacy promises. From the FTC notice regarding the settlement:

Despite the promises contained in its privacy policy, the FTC charged, Myspace provided advertisers with the Friend ID of users who were viewing particular pages on the site. Advertisers could use the Friend ID to locate a user’s Myspace profile to obtain personal information publicly available on the profile and, in most instances, the user’s full name. Advertisers also could combine the user’s real name and other personal information with additional information to link broader web-browsing activity to a specific individual. The agency charged that the deceptive statements in its privacy policy violated federal law.

I often point out that encryption software cannot be the silver bullet against data security issues. The above is a rather obvious proof of that.

Related Articles and Sites:
http://www.pogowasright.org/?p=28382

Data Protection: Frequent Flyer Miles A Hacker Target

sang_lee — Thu, 10 May 2012 23:53:00 GMT

In a clear sign that crime knows no limits when it comes to the imagination, cbsnews.com is reporting that hackers are after your frequent flyer miles. It's easy to protect your information if your laptop gets stolen by ID thieves (you ensure, today, that disk encryption like AlertBoot was used to secure the computer's hard disk). But how do you protect yourself against frequent flyer theft?

Frequent Flyer Miles Don't Feel Like Sensitive Data that Needs Protection

Frequent flyer miles. They are not money or currency. At the same time, you can't deny it's a medium of exchange. You can get stuff for those miles, be it trips, stays at hotels, or car rentals. Heck, they can even be donated for a good cause.

At the same time, I'm not sure that I feel that my frequent flyer miles belong to me. I mean, yeah, they're mine....but, I feel a certain detachment. The airlines control where I can use them, when I can use them, when they expire, etc. So, maybe it's because the airlines have more control over those miles than I do that I have that feeling of indifference.

For example, I have never actually felt the need to religiously protect my membership ID number like I do for my credit cards or Social Security number. I might think twice about providing the latter to an online site, but my frequent flyer number? Regardless, they do have a real value associated with them...and usually that's the condition that must be met in deciding whether something should be protected or not.

A New Phishing Attempt

According to cbsnews.com, crooks are emailing people "a trip confirmation or special offer, and asking them to enter their frequent flyer information." Of course, people give up their details. The security expert claims it's because people feel a sense of urgency, but personally, I'd probably do it because of the above-mentioned reason: it's a freaking frequent flyer number.

I mean, it's not as if you can order books from Amazon using your airline miles. At some point, you're probably going to have to show an ID when using those miles: the hotel, the airline counter, the car rental place, etc.

Another vector that's leaking your information? The trash can:

"Consumers probably ought to be taking those home with them, and disposing of them properly, instead of just throwing them in the trash bin at O'Hare," said Federal Trade Commission regional director Steve Baker. [cbsnews.com]

Incidentally, scams like these are the reason why the hacking of corporate databases is so problematic. You might think that there is little value to a hacker downloading a list of 100,000 email addresses and names. But, this is the foundation on which scams like the above are made possible.

And lest you think that this the airline mileage scam is nothing but an exercise in theory-making, a couple told cbsnews.com the story of how they lost over 160,000 accumulated miles because they were phished and someone used the miles on hotels. United Airlines eventually made them whole, but you can expect such customer-minded moves to dry up if there is ever an explosion on mileage phishing.

As a side note, this is an additional reason why companies may want to use data encryption to protect information that is not traditionally or legally considered to be sensitive in nature.

Data Encryption: More SAIC/TRICARE Technical Details

sang_lee — Thu, 10 May 2012 00:52:00 GMT

So, why was data encryption not used on the backup tapes that was lost by SAIC, triggering a TRICARE data breach that is currently #1 on HIPAA's "Wall of Shame"?

According to a boston.com report, it's because the system was designed in 1977. 1977? That's the year when Ron Rivest -- the "R" in RSA -- crystallized a way to create an asymmetric cipher, called the "most influential cipher in modern history."

Anyhow, returning to the story at hand (from boston.com, my emphases):

"Reading the data on the tapes would require knowledge of and access to specific hardware and software, which is commercially available, but would also require knowledge of the system and data structure on the tapes,’’ [Vernon Guidry, a spokesman for Science Applications International Corp] said.

Some privacy specialists, however, said that would not be much of a barrier for those seeking a high payoff. In the rapidly advancing world of data protection, computer tapes are considered archaic.

"To read that, you need to get your hands on the proper equipment, but the value of the data itself makes it worth the effort for identity thieves,’’ said Lillie Coney, associate director of the Electronic Privacy Information Center, a public interest research group in Washington.

The contractor [SAIC] uses portable reel-to-reel tapes to store the data, relying on an operating system originally designed in 1977. Such technology is so outdated that there is no way to encrypt the data - standard procedure for storage systems today.

It's hard to believe that this is the same company that has a 3.83 billion market capitalization. Backup tapes that use 1977 technology and sensitive data being transported in an employee's car?

Also, a detail that I was not aware of:

The lawsuit, which names Science Applications International Corp. and the Department of Defense as defendants, also contends that leaving the tapes unguarded in a vehicle, rather than transporting them in an armored car, violated industry practice in the data security field.

The detail that I am unfamiliar with is that transporting tapes in armored cars is an industry practice. Certainly, I've heard of it...but I've also heard of people driving in their own personal cars to pick up backup tapes and such. I think it's not inaccurate to say that industry practice has quite the wide range when it comes to handling sensitive data.

(Perhaps this is an area that requires government regulation because God knows self-regulation is not working).

You know what the really sad thing is? I'm willing to bet that if SAIC were to scrap whatever they're using right now and upgrade to a modern system, they'd not only be more secure but it would mean savings in operating expenses -- not only because they wouldn't be facing lawsuits because they can't encrypt their backup tapes, but because modern advances in technology have resulted in workplace efficiencies that have translated into real savings.

Data Security: Top 10 Phishing Hosting Countries

sang_lee — Wed, 09 May 2012 23:17:00 GMT

Often times, our (incorrect) sense of security leads us to do stupid things when it comes to data security, such as assuming that the back seat of a car is as good as computer drive encryption like AlertBoot when it comes to laptop security.

Along the same vein, it looks like we might not be getting the whole picture when it comes to data security when it comes to phishing. According to an annual report by Websense, the top 10 phishing-hosting countries are:

1. United States
2. Canada
3. Egypt
4. Germany
5. France
6. Romania
7. Netherlands
8. United Kingdom
9. Russia
10. Israel

You'll notice that the usual suspects such as China, the former Soviet eastern bloc, South Korea, and other countries that usually make the lists when it comes to the spread of viruses, trojans, etc. are not listed (Russia is the only exception that comes to mind, but look at its ranking -- #9).

The theory is that cybercriminals are using the squeaky-clean image of Canada (and other nations) to gain an edge in their phishing attempts.

I'm reminded of that counterintuitive observation: you catch the really dangerous diseases in hospitals.

Full Disk Encryption: External Drive Stolen From UK Judge's Chamber, Kind Of Lax Data Security

sang_lee — Wed, 09 May 2012 00:16:00 GMT

The Manchester Evening News (MEN) reports that a computer disk with sensitive information on up to 50 court cases was stolen, along with a cellular phone and about $500 from a UK judge's chambers. The portable disk was unprotected -- neither a simple password or with data encryption software like AlertBoot was used. This is a classic case of mistaking physical security with data security.

Judge's Chambers Secure

According to MEN, a convict -- Paul Dawson, who was working with a trusted court subcontractor -- sauntered into the chambers of Judge Andrew Gilbart QC (Queen's Counsel) at Manchester Crown Court and took his personal mobile phone, cash, and what appears to be an external, portable disk that contained case files.

The latter was not protected in any way. Well, actually, that's not true. Judges' chambers -- no matter where they are located in the world -- generally tend to be extremely secure. In fact, it's so secure that,

A security report into the theft says a member of staff tried to drop off paperwork in the judge's chambers at 11.15am on March 10, but the door was locked from the inside.

Judge Gilbart returned the following morning and discovered the burglary. The report states: "It was highly unusual for the chambers door to be locked."

It appears that the door was temporarily locked by Dawson as he rifled through the room.

The point, though, is that security is so tight that -- despite all the sensitive data one would expect to find in a judge's chambers, be it in electronic format or otherwise -- the door was generally left unlocked even if no one was inside.

The only reason Dawson got in was because he was working for the subcontractor, and the latter hadn't run a criminal record check.

Physical Security is not Data Security

No matter how secure a judge's room might be, it's not impregnable to intrusions. The above is just one such instance. Other ways might include:

Internal attacks: Members of staff -- legitimate ones, including security -- go "rogue"

Social engineering: A person who's not supposed to be within the inner sanctum somehow finagles his way in

All-out-attack: For some reason, people decide to force their way in...and succeed

Crazy guests: People invited into the chambers suddenly go berserk.

All of these would be rare occurrences...but they happen. And, considering what kind of information is kept in a judge's room, it's a little psycho that doors are kept unlocked. With such behavior in place, the argument that encryption software should have been used will probably fall on deaf ears.

Which is a shame because when it comes to digital data, encryption will almost always provide better protection than physical security. Like I noted the other day, AES encryption takes billions of years to crack. Try finding a guard or door that can guarantee that kind of performance.

European Laptop Thefts: UK Is No.1, Denmark Is No.2

sang_lee — Tue, 08 May 2012 12:02:00 GMT

While the US remains tops when it comes to laptop thefts worldwide, a report shows that the UK takes the top spot when only Europe is being considered (and it takes the second top stop globally). Denmark comes third in the world when it comes to laptop thefts. Interestingly enough, we see more of a demand for AlertBoot laptop encryption software from Europe than from the US.

Mobile Work Office Having an Effect?

The report shows that less than 10% of laptop thefts occurred in the traditional workplace (i.e., from offices). Instead, laptops were stolen from residences (14%) and cars (11%). When you consider that more and more work is done outside of the office (which makes sense, seeing how a laptop is meant to be portable), it only makes sense.

Not to mention that, generally, offices are generally better protected than residences from physical intrusions.

The report also showed that laptop tend to be stolen more during the summer. While it's believed that "employees are usually on holiday and laptops" and "left unsecured" their laptops in their homes, I have a different theory: thieves, like everyone else, tend to be more active when the weather is fairer.

I mean, people keep their laptops unsecured in their homes when they vacation during winter, too, ya know?

All the more reason why the modern workforce must look into using disk encryption software. With a managed encryption solution like AlertBoot, you can combine the demands of the workplace (high security, centrally managed encryption policies by the IT department) with the flexibility that employees require (encryption over the cloud, no matter where the employee is. No need to come in and wait for encryption to be installed on a computer).

Data Encryption Software: How Secure Is AES Encryption?

sang_lee — Tue, 08 May 2012 07:19:00 GMT

I often write about the near impossibility of breaking AES encryption, and I am not alone: An article at eetimes.com (link at bottom) comes to the same conclusion. Another take on why drive encryption software like AlertBoot is considered to be very safe when it comes to protecting a laptop full of sensitive data.

A Billion Billion Years

As you see, I'm not the only who points out that "cracking" AES encryption would take a very long time (a billion billion years -- not to be confused with billions and billions of years). On the other hand, I don't want people to be left with the impression that encryption software is the be all, end all of security.

Sure, no one you know will be around when a laptop protected with AES-256 encryption is cracked billions of years from now; however, figuring out the encryption key is not the only way to gain access to an encrypted computer.

Why Discuss Weaknesses to Encryption?

You might think that I'm biting the hand that feeds me by pointing out how the security afforded by encryption software can be curtailed. Nothing could be further from the truth.

The weaknesses that I'm about to discuss, are ways that you (not a hacker, but the owner of the data) could compromise your encrypted laptop's security.

Weaknesses When It Comes to Disk Encryption

The first is the most obvious one: choosing a weak password. This warning has been done to death, but let's face it: passwords matter. As the eetimes.com article notes, the strength of the encryption key comes from its length. A longer key means that there are more keys of the same exact length, which in turn means more guesses to find the right one.

What's true for keys is also true for passwords. The longer and more random a password is, the more time a hacker will have to spend on resources (time, money, etc) to find it.

The second weakness is also related to passwords: don't write them down and keep them in the vicinity of the laptops that are being protected. A hacker won't be spending anything but emptying his belly of laughs.

The third is never shutting down your computer or always keeping it in hibernation or sleep mode. The effectiveness of full disk encryption (FDE) is at its peak when the computer is shut down. It's most vulnerable when it's up and running (in order to use a fully encrypted computer, you must get rid of the encryption). A computer is protected in hibernation or sleep mode...but, there are some ways to finagle passwords or encryption keys in something called "the maid attack" or "the janitor attack." It's not an attack your average laptop thief will be able to carry out, so it's less of a problem, but still...it's always advisable to shut down your computer when moving it about.

Laptop Encryption Software: Apple OS 10.7.3 (Lion) FileVault Encryption Fumble

sang_lee — Mon, 07 May 2012 23:11:00 GMT

The latest Apple encryption blunder shows why digital data security is always risky, why it works despite the ever-present risk, and why you need to go with vetted products (which is why the centrally managed encryption from AlertBoot uses FIPS-validated Sophos SafeGuard).

Update 10.7.3 Turns On Debug Log -- There's Always Risk

According to zdnet.com, an Apple programmer accidentally left on a system-wide debug log file that records the login information of all who logged in since the installation of Max OSX update 10.7.3. Not surprisingly, the debut log stores all the information in plaintext, including the passwords.

However, it only affects "anyone who used FileVault encryption on their Mac prior to Lion, upgraded to Lion, but kept the folders encrypted using the legacy version of FileVault is vulnerable."

It has expressly been noted that users of FileVault2 are not affected. But then, FileVault2 is a true full disk encryption implementation and was designed with security in mind. It's a weird thing to say, isn't it? After all, encryption is encryption: FileVault (the first), one assumes, would also have been designed with security in mind.

But, Apple's first foray that was FileVault included a litany of problems, including software applications that stopped working after turning on FileVault and sensitive data not being protected (because it lied outside of the encrypted image). It was, to say the least, not a particularly popular security feature. Hence the birth of FileVault 2.

As you can see, encryption is not a holy grail when it comes to security: sometimes, it just doesn't work as expected.

But, It Still Works

That being said, the beauty of computer data security is that there are people who are constantly looking into the issue (i.e., attacking the encryption to see if it truly does what it claims it does). Take the Apple bug above:

The flaw was first reported by a security researcher David Emery, who posted his findings to the Cryptome mailing list. The bug has not been corrected by any subsequent updates.

In fact, as zdnet.com points out, a lot of people had been commenting on the bug since OSX 10.7.3 was released on February 1, 2012. So, there are people who are constantly poking and prodding to make sure encryption is working the way it's supposed to.

This might feel like a bad thing, but in the end it works towards achieving an encryption product that stands up to attacks. (In a way, that's what encryption vetting processes do -- it attacks the submitted encryption product to see if there are any known vulnerabilities.)

Plus, keep in mind that this flaw affects a particular niche: it doesn't affect FileVault prior to the 10.7.3 update, and it doesn't affect FileVault2. Those two are still working as expected. (In fact, it's enough to make one wonder why Apple hasn't released an update or a patch since 10.7.3. I mean, one would assume that the fix to this issue is to "turn off" the system-wide debug log file.)

The point to the story: encryption works. Once in a while, you'll see a vulnerability crop up that might affect one product or an entire encryption algorithm (for example, right now AES-128 is a tad bit more secure than AES-256). The occurrence and severity of such a vulnerability will depend on how well the encryption software is created. However, it will literally take the skills of a security researcher to figure it out.

What about the time lag in issuing a fix? Well, I can't speak for Apple, but I can tell you that if an issue were affecting a product that was offered by a company focused on data security only, a fix would be offered ASAP.

Incidentally, this is why you should be using a data encryption product that has a stamp of approval (like FIPS validation) as opposed to any product that features "encryption" in its title. There are plenty of encryption tools out there that do encrypt data but don't really provide much in terms of security, either because it has vulnerabilities like Apple's last update to FileVault, because it uses weak encryption algorithms, or other reasons.

Disk Encryption: Bin Laden Didn't Use It. Did He Need To?

sang_lee — Fri, 04 May 2012 22:13:00 GMT

You've probably heard by now that US authorities released a number of Osama Bin Laden's documents that were captured last year during the Abbottabad compound raid. One of the surprising revelations? Osama Bin Laden didn't use proper security when it came to his electronic files. For example, USB sticks, memory cards, and other storage devices were not protected with disk encryption software like AlertBoot (not that AlertBoot would sell services to terrorist leaders and their henchmen. But, the same encryption found in AlertBoot -- AES-256 -- is available in free encryption software, so terrorists do use it).

There are two camps of thought when it comes to this revelation: those who think that Bin Laden was being cavalier with his files and those who think that there was no point to encrypting files.

He Doesn't Need To: What's the Point?

I first ran across the Osama story on slashdot.org. The reactions about the state of security were mixed, but there were plenty of commentators who pointed out that Osama was being pretty logical in not using encryption.

He only communicated via courier -- and we're not talking about FedEx -- so the threat of an unknown interception -- or any type of interception -- was low.

The released documents are, for the most part, not something that would require encryption. I mean, Osama calls for death to America? That's not an encryption-worthy secret.

If Osama was ever captured, they'd probably get the password to access the files from him: xkcd.com.

Even if Osama is not captured, the US would put its considerable intelligence resources on cracking encryption.

Etc.

Well, that sounds pretty reasonable. I mean, the only reason why anyone would use encryption software to safeguard data would be because the revelation of said data to undesirable people would be "bad": it would put people in danger (bin Laden and his cronies are already in danger); it would have legal repercussions (bin Laden already in legal trouble); it would alert others about their plans (we already know those plans: kill people. Plus, we also know independent cells operate quite autonomously)... in other words, there's very little to protect there.

Painting a Mosaic

I'd argue, however, that the viewpoints above are pretty shortsighted. It's the same type of argument you'd find in justifying not encrypting a massive database of email addresses, for example. Since email addresses are not really personal data (think about it: you can have multiple ones, and conceivably someone else can sign up with your old email handle if you opt to kill an account), they don't have to be protected under most (all?) US state and federal laws.

But, as we know, those email address can be used as a lever to real criminal activity. Likewise, any details, however mundane they may be, could be the lever to crack down on significant aspects of a criminal organization. Even if you can't paint a detailed picture, a mosaic is more than enough in many cases.

But, hey, I'm not losing any sleep over this latest "non-encryption snafu."

Incidentally, The Daily Show with Jon Stewart has an interview Peter Bergen on the Abbottabad raid where Bergen sheds a little light on how the CIA found Osama...and proves that even the smallest detail can be of high value.

Android Security: First Drive-By Malware Site Reported

sang_lee — Fri, 04 May 2012 03:00:00 GMT

After looking through my newsfeed, I've come across two stories dealing with malware. First, gizmodo.com reports that Android devices can now be infected with the malware called "NotCompatible" just by visiting a site (such an attack is known as a drive-by attack in data security parlance). Second, wsj.com reports on a Symante finding that religious sites are more infectious than porn sites.

First Drive-By Malware for Android

However, this attack is only viable if "an Android device that isn't fully patched visits one of these sites." Before you decide to breathe a sigh of relief, though, take into consideration that many Android phone manufacturers are slow in updating whatever fork of Android OS they've decided to use. In the mobile device world, sometimes it's just impossible to get the adequate level of security even if you are a conscientious patch updater.

The real silver-lining is that

This threat does not currently appear to cause any direct harm to a target device, but could potentially be used to gain illicit access to private networks by turning an infected Android device into a proxy. [gizmodo.com]

There is an easy way to protect yourself: turn off the "install from unknown sources" option. The problem with this option, of course, is that it will also affect legitimate, bona fide sites.

Gizmodo also recommends the use of mobile antivrus apps (no argument from me there).

Religious Sites More Harmful Than Porn Sites

The other story: The Wall Street Journal reports that the most harmful sites, "in terms of risk from malware infection," are religious websites. A study by Symantec found 115 threats, on average, at religious sites whereas porn site had an average of 25 threats per site.

Other highlights from the report by Symantec (per wsj.com):

Threats to mobile devices, almost exclusively on the Android platform, is growing. The threat, however, is tiny when compared to the PC environment (403 million vs. 4,000).

Half of targeted attacks are directed to organizations with fewer than 2,500 employees. Companies with 250 employees or less were targeted 18% of the time.

Malware attacks via social networks are up.

Personal Data Protection: FL Department Of Children And Families Data Breach Affects 100,000

sang_lee — Thu, 03 May 2012 21:47:00 GMT

It is being reported by wftv.com that over 100,000 child care workers are being alerted by the Department of Children and Families (DCF) of a Florida-wide data breach. In this day and age, how is it possible that someone puts SSNs on the internet without the proper security in place (such as data encryption programs like AlertBoot)?

Vendor Causes Breach

According to the letter, DCF employees' personal information -- including Social Security numbers -- were stored online. Personal information is required to carry out background checks. The vendor who stores the information had it stored on the internet.

Technically, there is nothing wrong with that. While there might always be a little room for concern, the use of proper security tools like encryption software would ensure its protection (all the stories about on-line hacks tend to involve instances where proper security procedure was not followed).

The problem? According to wftv.com "the vendor that stores the information had it on the Internet. It wasn't easily accessible on any search engine, but it was not password protected." That's problematic. On the one hand, the fact that it wasn't accessible via a search engine is great: it means Google hacking -- the practice of finding a website's vulnerabilities by doing searches via a search engine -- won't work.

On the other hand, it also means that if someone managed to stumble upon the file, he would have had no obstacles in accessing the file.

And that's crazy. It's like pirates not burying their booty but just laying it there on a deserted island because...hey, it's a deserted island!

Big Data: ICO Aggregating Data To Fine Private Sector

sang_lee — Thu, 03 May 2012 00:42:00 GMT

The UK's Information Commissioner's Office (ICO) is looking to compensate the dysfunctional imbalance that currently exists when fining British organizations that suffer a data breach. (As detestable as it may sound, the ICO has shown a willingness to fine companies that experience a data breach, adding insult (and injury) to injury. But, it could be argued that the companies brought the data breach upon themselves. For example, by allowing employees to tote around laptop computers without first securing the devices with data encryption software like AlertBoot.)

80% of Fines on Public Sector

As zdnet.co.uk reports, the ICO " imposed 14 civil monetary penalties against [organizations] since November 2010, with 12 being against public sector [organizations], and one against a public sector service provider". I created and recently updated a list of ICO DPA penalties. That, of course, only leaves two instances where private companies were fined for a breach of the Data Protection Act.

Private Companies Account for over 30% of Breach Disclosures

This disproportionate penalty ratio exists despite the fact that private companies account for over one third of data breaches disclosed to the ICO. In fact, when you consider that private companies are not under any obligation to make these revelations to the ICO, one has to wonder whether breaches of the DPA at private organizations wouldn't account for a larger share of the pie. Indeed, a recent report by PricewaterhouseCoopers (PwC) has found that 45% of large businesses were in violation of data protection laws.

(I assume that, given the choice of not reporting a data breach, a company will probably not do so. Hence, the ones that do report to the ICO are outliers. I could put on my rose-colored glasses and assume that British companies report it out of a sense of duty, a sense of respect, the need to do the right thing. But, then, how do explain the fact that companies are caught not deploying encryption software? One would presuppose that a sense of duty would guide companies to ensure that mistakes are minimized in the first place.)

Is the ICO Implying that Breaches at Private Organizations Don't Matter?

A contributor to microscope.co.uk, after hearing that the public sector accounts for the bulk of fines, ponders whether

Now we might feel that data breaches deserve to be punished in order to act as a deterrent, but if we do, that policy needs to be applied equally across the public and private sectors. It may well be that the data held by public sector organisations (sic - at least, in the US) is more sensitive than the data held by private sector businesses, but is the ICO really suggesting most data breaches at private organisations are of information that is relatively worthless? Because that seems to be the message.

I doubt that that's the message. But, such criticism is not new. I looked into the situation in this page. In summary, the ICO claimed that there are better ways of resolving breaches of the DPA, and that it can't just hand out fines as it sees fit. Penalties can only be handed out when specific conditions are met.

Aggregate Complaints: Big Data Brings Balance

Continuing with the zdnet.co.uk story, the ICO has announced that,

To try to redress the balance of fines, the ICO will start to aggregate complaints from people about potential breaches of the Data Protection Act...

The next phase for us is to make more sophisticated use of all the information we get in from consumer complaints, to analyse (sic)[it]," said Graham. "Not just to decide whether a breach is likely or unlikely under the Data Protection Act, but to aggregate some of the information we're getting to spot who are the serial offenders, which would build a case for action on more occasions in the private sector."

This has the potential to completely change the game. Instead of just hammering those that step up to the plate and admit they had a breach, the ICO could go after cases where an organization with the duty to report a breach has not done so, or go after private companies that can be fined for breaches of the DPA but are not required to report said breach (that's one badly-written piece of legislation right there).

Such a move dovetails nicely with the current penalty amounts. Among the criticisms the ICO has received since it gained the power to directly hand out monetary penalties, an oft-remarked one is that the ICO's fines come nowhere close to the £500,000 limit (the highest to date is £140,000 assessed on Midlothian Council earlier this year).

The ICO counters with the observation that the fines ought to send a signal and not just punish the companies that are penalized. The latest move by the ICO could mean higher penalties that get closer to the £500,000 limit -- for example, a public sector data breach involving 20,000 people gets a fine of £100,000, but a public sector data breach involving 20,000 people that goes unreported (contrary to law) gets a fine of £200,000 or whatever is deemed fit. After all, there ought to be consequences for violations of the DPA in other areas that the exposure of personal data.

Data Encryption: Google Engineer At Center of WiSpy Meant To Collect Data

sang_lee — Wed, 02 May 2012 07:56:00 GMT

Last week, I had offered some observations on Google's problems with their "WiSpy" case. Since then, of course, more revelations have been brought forth, such as the name of the Google engineer who's at the center of the controversy.

It's quite obvious now that, contrary to Google's claim, the collection of personal data in their Street View project was not "accidental." From cnet.com:

The FCC speaks of a rogue engineer who deliberately wrote code to collect the data, and the agency questions whether the employee's colleagues and managers knew, or should have known, about the code. Among the claims made by FCC investigators in the full document, as reported by the Times:

The engineer told two colleagues, including a senior manager, about the code.

The engineer also distributed to the Street View team a document that said the data collection would take place.

A senior manager said he had preapproved the document before it was written; Street View managers said they hadn't read the document; and a colleague recalled receiving the document but didn't remember any reference to such data collection.

A different engineer, who worked on a line-by-line debugging of code for the Street View project, said he didn't see the data-collection code.

Engineers on the project told the FCC they weren't required to get approval from project managers before modifying the code.

The rogue engineer was working on Street View only as a side project and was interested in collecting the data to see if it could be used in other Google products. He dismissed privacy concerns because the Street View cars wouldn't be near "any given user for an extended period of time" (though he made a note to discuss the issue with a product counsel).

The engineer reviewed the data at least once for info on frequently visited Web sites, thinking the data could help Google's search team. But when a member of the search quality team said such data had no value, the engineer dropped the idea.

The FCC also accuses Google in the report of holding back an e-mail that discussed the engineer's review of data with a senior manager on the project, the LA Times reports.

Does this in any way change the position that I held last week?

Nope. What happened is, obviously, legal in the US (but not so in other parts of the world). Did Google "do evil"? I still don't think so. At least, I don't think there was any evil intent behind the collection of data.

Was it a stupid move? Yeah, it was. This part is especially galling:

He dismissed privacy concerns because the Street View cars wouldn't be near "any given user for an extended period of time" (though he made a note to discuss the issue with a product counsel).

In other words, an extremely smart guy took such issues into consideration and then just waved them away like so many flies without actually looking into the situation.

But you know what? To me, it's still understandable. Prior to my own research into European privacy laws I, too, would have assumed that collecting such data was not illegal based on the circumstances. On the other hand, even with that assumption, I'd probably have consulted with the legal department knowing that the project would be global in its scope. And, if your reasons are pure, you tend to think that no harm will come of it.

What's not understandable is how Google can claim that this is the job of one engineer and that no one had no idea it was going down. If he had put in the effort to hide what he was doing, maybe such a tale wouldn't sound outlandish. But that's not what happened; he was very forthright about collecting data. The engineer appears to have sent communiqués on what he was up to. No one, absolutely no one, read his missives?

Whatever the facts may be, Google must excuse the public at large for doubting the company's claims of innocence. Like many of its products and services, the claim is just too convenient.

PS - As an aside, the recent goings-on remind me of Seth Godin's lecture at Google. If you watch the video, at around the 6:00 mark, Godin talks about an incident he had in New York: He was walking around in a Google shirt, and some lady selling peaches wants to know whether he works at the company, and tells him that Google is her friend. Godin is forced to admit that "nobody cares about you (your brand)...but people care about Google."

But, he notes, "if you blow it just a few times in a row, they won't care about Google anymore."

Data Encryption Software: Accretive Health Asks Court To Throw Out MN AG Lawsuit

sang_lee — Tue, 01 May 2012 08:20:00 GMT

Accretive Health, the catalyst for HIPAA data breaches in last year's Fairview and North Memorial hospitals in Minnesota, has asked a judge to dismiss a lawsuit brought by the Attorney General of Minnesota. The situation could have been avoided had Accretive used laptop encryption software such as AlertBoot, like they were supposed to.

I've covered the story before here which provides links to some other posts.

Accusation: AG is Trying to Win in Public Opinion Sphere, Not Court

Accretive has filed a motion to dismiss the case, accusing Lori Swanson -- the Minnesota Attorney General -- of making "factually baseless and legally indefensible" allegations (businessweek.com).

A spokesperson for the AG's office noted that "the dismissal request is a 'typical first step' for a corporate defendant" and that "We're very confident in the legal claims that are laid out in the complaint."

The accusations do not just revolve around the loss of laptops. You can read more about the story at businessweek.com or bloomberg.com (different links, same story).

Accretive, in what appears to be a strategy to diffuse concerns, has issued a press release. For those interested in the HIPAA aspect to the story, this is their argument (marketwatch.com):

The core of this case involves the criminal theft of a password-protected laptop. Under the federal Health Insurance Portability and Accountability Act (HIPAA) and the Minnesota Health Records Act, a company cannot be held liable for the unforeseeable criminal act of a third party stealing a corporate laptop. Further, in the ten months since the laptop was stolen, there is no evidence (and the Attorney General does not even claim) that any patient data has been compromised. As a result, in the absence of any injury, the Attorney General lacks legal standing to pursue claims under HIPAA and the Minnesota Health Records Act as a matter of law.

AGs Have Power to Prosecute HIPAA Violations

State AGs have been given the power to enforce HIPAA (which the AGs put to use in the Health Net case). I'm pretty sure the AG's argument is not based on the theft of laptops. Like the hhs.gov site notes:

The Health Information Technology for Clinical and Economic Health (HITECH) Act, part of the American Recovery and Reinvestment Act of 2009, gave State Attorneys General the authority to bring civil actions on behalf of state residents for violations of the HIPAA Privacy and Security Rules. The HITECH Act permits State Attorneys General to obtain damages on behalf of state residents or to enjoin further violations of the HIPAA Privacy and Security Rules. [my emphasis]

So, the question to ask here is not "was anyone harmed?" but "did Accretive violate HIPAA Privacy and Security Rules in any way?" Gee...a laptop with the information on nearly 17,000 Minnesota residents was stolen. Per Accretive's own admission, the computer was not secured with encryption software when it should have been, and the laptop was stolen from the back seat of a rental car.

Does that sound like people's PHI (protected health information) was secured properly? No? Would it be overreaching to conclude that it was a violation of HIPAA Privacy and Security rules? I mean, the rules do require proper protection of people's health data, even if encryption is not required (but only if other security is present). An unencrypted laptop in the back seat of a car doesn't quite meet the requirement.

More Instances of "PHI Breaches"

"PHI breaches" in quotations because, technically, it wasn't a breach. According to twincities.com, Accretive had a similar situation in June 2010, when another employee had his laptop had been stolen from his car while parked outside a restaurant.

Sound familiar? It's the same exact scenario that developed in 2011. There was a big difference, though: the 2010 laptop was encrypted.

While some point to this as a pattern, I'd disagree (not the least because two instances do not constitute a pattern). Sure, laptops were stolen from cars. But, the presence of encryption makes a world of difference.

If anything, the 2010 encryption would show that Accretive does not have a pattern of data breaches, even if they do have a pattern of losing laptops from parked cars. And, let's face it, the latter is meaningless to all but the guy working in the procurement department. And whichever company is insuring these machines.

Stock Takes Nosedive

It just doesn't look good for Accretive. That must be the reason why its stock took a hit: on April 24, the stock was averaging $19 per share or so; currently, it's at around $9 per share. It's probably also the reason why Accretive came with their guns blazing, noting how the AG's charges against the company do not have any merit. Per my experience, companies that caused a massive breach tend to be humble about their data indiscretions.

And to think, all of this could have been avoided with the simple installation of laptop encryption software.

Data Protection: Aneurin Bevan Health Board Fined £70,000 By ICO

sang_lee — Mon, 30 Apr 2012 23:00:00 GMT

Aneurin Bevan Health Board (ABHB), a Welsh health board, has become the first NHS organization to be fined under the Data Protection Act. Based on the number of breaches that the NHS has been reporting over the years, it's surprising that this hasn't happened sooner. For example, plenty of USB memory sticks, external hard drives, and laptop computers that were not protected with full disk encryption like AlertBoot have been lost or stolen over the years.

In the ABHB case, the cause of the breach defies belief: a mistake in spelling a patient's name, and a secretary that apparently just stabbed a guess at what the name might be.

£70,000 for One Man's Report

ABHB was fined £70,000 after sending a patient's health report to the wrong person. The incident took place in March of last year, which beckons the question: why is ABHB being fined now?

According to various sources, the breach's Rube Goldberg machine-like series of events began with a doctor (in some cases, a consultant) emailed a letter to a secretary for formatting. In the letter, the patient's name was misspelled, as well as spelled correctly. The letter, however, did not contain enough information for the secretary to identity the patient.

At this point, one would imagine the secretary emailing the doctor and asking him/her to identify the patient. But, no, the report was sent to another patient with a similar name.

According to guardian.co.uk,

Stephen Eckersley, the ICO's head of enforcement, said the mistake could have been prevented if the information had been checked before being sent out.

Even more worrisome,

An investigation by the ICO found neither member of staff had received training in data protection and there were inadequate checks in place within the board to ensure personal information was only sent to the correct recipient.

These poor practices were also used by other clinical and secretarial staff across the organisation. [bbc.co.uk, my emphasis]

A spokesman for ABHB had this to say:

We have 14,000 staff and have hundreds of thousands of contacts with patients each year, with systems in place to discharge these patient contacts confidentially," said the spokesman....

This was a genuine and unintended individual error, which was self-reported by the organisation to the information commissioner, because of the importance the health board places on information governance and in line with the commissioner's own guidance. [bbc.co.uk]

While I don't doubt that ABHB places a lot of emphasis on patient data security, and that it has systems in place...well, it doesn't do one much good if they're upended by something so simple as not checking on who the patient is, does it?

Consider, for example, a letter that addresses both a "Mr. Brown" and a "Mr. Browne." Are you just going to gloss over the difference in spelling? Which one is the misspelled name? The right move would be to get back to the original person who wrote the missive.

The Road to Hell is Paved with Good Intentions

And the road to data breaches is paved with "genuine and unintended individual errors."

For example, what is the claim that is generally made when a laptop computer with sensitive data goes missing? That it was an unintended error. A one-time mistake. Won't happen again. They had systems to ensure "certain things don't happen."

But did they use medical data encryption software, which pretty much guarantees that "certain things don't happen"? No, of course not. And yet, an organization finds itself "disappointed" to be fined under the law.

While it might be a poor comparison, take this example. If you purposefully run over someone with your car, that is murder. If you run over someone without the intention of killing that person, it's manslaughter. Whatever the intention may have been, both are followed with punishment because real harm was done.

I don't see why it should be any different for data breaches.

Computer Hard Drive Encryption: Desert AIDS Project Announces Data Breach

sang_lee — Sat, 28 Apr 2012 03:30:00 GMT

According to a letter sent to clients of Desert AIDS Project (DAP), the theft of an office computer has triggered a data breach. It has not been revealed whether the computer in question was protected with drive encryption like AlertBoot. But, a "strong password" was used, so there's that.

Office Break-In

Desert AIDS Project reported to clients and the State of California that a thief broke into DAP offices on April 12, 2012 and stole a receptionist's computer.

The computer did not contain medical details nor certain personally identifying information (SSNs, driver's license number, credit or debit card number, health insurance number, or other account numbers). However, there was a spreadsheet that contained client names, staff names, client status (active, discharged, etc), internal client identification number, and date of birth.

The letter goes on to note that the "spreadsheet itself does not include DAP's name" but that "other documents stored on the stolen computer may reveal its connection to DAP."

Not to be sarcastic, but so does the fact that the thief took it from the office, doesn't it? I mean, it's not as if the computer was stolen from a car parked in a shopping mall garage. The connection to DAP is pretty obvious.

Encryption or Password-Only?

The use of a strong password, unfortunately, is meaningless. A strong password tends to be long, random, and is composed of upper and lower case letters, numbers, and special characters. The password ASF23$GaSDFSAfaSdfsad@TR3r23332rgERVfwfWwGwhLKu,MNwWQF/./.<ewqf would be considered to be a very strong password.

The problem is that if this password is not securing a computer protected with disk encryption, then getting around it is pretty easy. You just pop out the hard drive and connect it to another computer.

In effect, the popped-out drive becomes an external hard drive and the password never comes into play because the operating system on that disk lies dormant (whereas the active operating system is the one set up by the thief or hacker).

When you're in a business where patient confidentiality is at its utmost, you must ensure that you've got more than adequate security. At the same time, you can't go crazy: DAP probably can't afford all the things an outfit like Goldman Sachs is using to protect their data.

But, some are more affordable than others while offering enhanced protection. Like centrally managed encryption software that uses the AES-256 to guard a computer's contents.

Data Security: Fake Skype Encryption Is Really Trojan In Disguise

sang_lee — Fri, 27 Apr 2012 22:39:00 GMT

The Trend Micro blog brings us news that a website (blocked for our own good) is offering software that purportedly provides encryption for Skype (Skype Encription v 2.1.exe). Which seems redundant because encryption is already used in Skype (it is the same that is used in AlertBoot hard drive encryption: AES-256).

You can corroborate this by visiting the official Skype support page.

Less Redundant than It Appears

As it turns out, the software in question doesn't actually encrypt anything. Rather, it's a Trojan for injecting DarkComet Version 3.3, which allows hackers to take control over a computer. One thing of interest that Trend Micro noticed was that "SyRiAnHaCkErS" (Syrian Hackers) appear to be behind this latest software offering.

False Flag

Why would anyone be looking for software that encrypts Skype communications? And what's the Syrian hacker connection? As Trend Micro helpfully points out, Syria's ongoing uprising (part of Arab Spring) has spilled over into cyberwarfare, as seen in this CNN article. For example, an aid worker was tricked into installing spyware:

The man chatting with Susan via Skype passed her a file. She recalled what he said to her to coax her to open it: "This makes sure that when you're talking to me, it's really me talking to you and not somebody else."

She clicked on the file. "It actually didn't do anything," she said in a baffled tone. "I didn't notice any change at all."

No graphics launched; no pop-up opened to announce to the user that the virus was being downloaded. The link appeared to be dead or defected, said Othman.

But something did happen. Susan's computer was infected with spyware that monitors her computer activity. What did that Trojan do? According to Symantec:

The Trojan then allows a remote attacker to perform the following actions on the compromised computer:

Capture webcam activity

Disable the notification setting for certain antivirus programs

Download and execute arbitrary programs and commands

Modify the hosts file

Record key strokes

Retrieve system information about the computer

Start or end processes

Steal passwords

Update itself

Skype Already Uses Encryption

As I already mentioned before, Skype uses encryption to protect its calls. The encryption keys are generated by the computers that are engaged in the calls, and there is no central command control structure for keeping track of the encryption keys. At least, this was true as far back as 2009, as can be seen in this video. In the comments section, you'll see comments that cast suspicion.

Such arguments can be countered with actions, though. For example, India threatening to ban Skype because the government can't monitor the calls and Germany complaining about the same.

Unless these are some elaborate false flag misinformation exercises, it's pretty apparent that Skype's calls are secure. Indeed, it's the reason why AlertBoot managed disk encryption software uses the same AES-256 algorithm to secure information on laptops.

Laptop Encryption Software: Fresno Doctor Offering Reward For Stolen Computer

sang_lee — Fri, 27 Apr 2012 00:46:00 GMT

A doctor who works with children in the Fresno area has offered a reward for the return of her computer. It does not sound as if hard disk encryption like AlertBoot was used to protect the device.

Car Break-In, Yet Again

According to kmph.com, Dr. Gloria Traje-Quitoriano's computer, full of patient information, was stolen from her husband's car. The PHI include names, home addresses, phone numbers, dates of birth, and Social Security numbers.

The doctor is particularly concerned about "the files because they can get identity, my patients' identity." She is hoping that a $500 reward for the safe return of the computer may curtail the ramifications of the laptop theft.

Incidentally, this is why I'm assuming that the computer was not encrypted. PHI encryption pretty much ensures that thieves will not be accessing a computer. So, there wouldn't be a realistic concern on the safety and integrity of patient data, and you certainly wouldn't be offering a $500 reward -- unless your objective is to regain your hardware.

Maybe If You're Lucky

The return of the unprotected laptop computer, though, does not automatically mean that patient data is safe. Remember, if there is nothing preventing unauthorized access to the computer -- like encryption software that requires the correct password -- a thief could easily boot up the computer; copy any sensitive files to another computer (that he probably stole); and return the computer to the doctor to collect the $500.

Depending on the situation, such as whether the doctor bills Medicaid, this is most certainly a breach of HIPAA Security rules. An unencrypted laptop has no business being inside a car. If you frequently travel with a device that stores patient data, you have to encrypt.

Mobile Device Security: InfoSecurity Europe Survey Shows 44% Don't Encrypt

sang_lee — Thu, 26 Apr 2012 22:20:00 GMT

Paranoia. It's one quality that grows in you -- if you didn't suffer from it already -- if you work in the information security space. But, apparently it doesn't affect everyone. A survey was taken among participants of London's InfoSecurity Europe show last year. The show being what it is, it's not far-fetched to assume that the crowd is "security aware." But, 44% of those who admitted to carrying sensitive information on their mobile device did not encrypt data.

There are many mobile devices out there, but in today's BYOD culture, if you're carrying sensitive data on your mobile device, chances are that you have a smartphone, such as an iPhone or an Android OS-based phone.

These devices already come with powerful encryption. All one has to do is turn it on.

Of course, statistics being what they are, it could be that this 44% represents a tiny number of people. Remember, it's 44% of those who carry sensitive data. If you're truly paranoid, you ensure you don't carry sensitive info on your mobile device.

Assuming such paranoia affects half the crowd, the above 44% would represent only 22% of the entire crowd. I guess it's not a stretch to assume that about a quarter of people who attended London's InfoSecurity Europe show were regular laypeople.

But, data breaches will bite anyone. Regardless of your level of paranoia or job description, if you carry sensitive data on your mobile device, you should encrypt your device.

Do it right now.