Let’s look at some data

Paul Murphy has made some predictions for 2007. EC readers can judge their value.
Mr. Murphy makes one comment on data breaches that I can’t resist reacting to (after the jump), however.

What’s needed is first for someone in the United States to launch a national class action on behalf of the people affected by one of these “incidents,” and secondly for the jury involved to vote substantial damages mainly on the basis of expert testimony to the effect that using Microsoft’s client-server technologies to store and access identity related data is an industry dumbest practice.

The message, it seems, is that flaws in “Microsoft’s client-server technologies” are the cause of much of the data loss pain we see reported daily. I’m not a lawyer, so I am going to ignore the question of whether it is possible at all to show damages in the legal sense from one of these breaches, unless and until one actually suffers identity theft tied to a breach. That is itself a difficult thing to show, but to give Murphy his due, I will simply assume it away and focus on the claim that problems with Microsoft products cause data loss.
Here’s a table of 19 of the top 20 data loss incidents from Attrition.org‘s DLDOS archive (the most complete source which is freely available), as measured by quantity of affected records:

+------------+---------------------------------------+---------------+------------------+
| Date       | Name                                  | TotalAffected | Type             |
+------------+---------------------------------------+---------------+------------------+
| 2005-06-19 | Visa MasterCard American Express      |      40000000 | Hack             |
| 2004-06-24 | America Online                        |      30000000 | Fraud - SE       |
| 2006-05-22 | U.S. Department of Veterans Affairs   |      26500000 | Stolen Computer  |
| 2003-03-06 | Data Processors International         |       5000000 | Hack             |
| 2006-06-13 | KDDI                                  |       4000000 | Hack             |
| 2005-06-06 | Citigroup                             |       3900000 | Stolen Tapes     |
| 2006-09-07 | Chase Card Services                   |       2500000 | Disposal         |
| 2005-12-21 | LaSalle Bank                          |       2000000 | Lost Tapes       |
| 2005-06-30 | DSW Shoes                             |       1496000 | Hack             |
| 2006-10-26 | Colorado Department of Human Services |       1400000 | Stolen Computer  |
| 2006-05-31 | Texas Guaranteed Student Loan Corp.   |       1300000 | Lost Media       |
| 2005-02-26 | Bank of America                       |       1000000 | Tapes            |
| 2006-06-14 | American Insurance Group              |        930000 | Stolen Computer  |
| 2006-12-12 | UCLA                                  |        800000 | Hack             |
| 2006-10-24 | Chicago Board of Election             |        780000 | Web              |
| 2005-05-23 | Bank of America / Wachovia            |        676000 | Fraud - SE       |
| 2006-09-08 | Linden Lab . Second Life              |        648420 | Hack             |
| 2005-07-06 | Time Warner Inc.                      |        600000 | Stolen Tapes     |
| 2003-01-03 | United States Department of Defense   |        562000 | Stolen Computers |
+------------+---------------------------------------+---------------+------------------+

Clearly, stolen Solaris or Linux boxen are as easy to grab data from as stolen Windows machines (just ask anybody who has forgotten the root password and used a boot CD to facilitate editing /etc/passwd), and lost tapes and disposed information are operating system agnostic, so let’s omit the thefts, tape losses, and “disposal”, and consider the minority which remain.
2005-06-19 – Visa MasterCard American Express
This is better known as CardSystems. The FTC extensively investigated this matter, and made a number of claims about what CardSystems’ actions (or lack thereof). Adam handily listed them in a previous post. According to the FTC, CardSystems:

  • created unnecessary risks to the information by storing it;
  • did not adequately assess the vulnerability of its computer network to commonly known or reasonably foreseeable attacks, including “Structured Query Language” injection attacks;
  • did not implement simple, low-cost, and readily available defenses to such attacks;
  • did not use strong passwords to prevent a hacker from gaining control over computers on its computer network and access to personal information stored on the network;
  • did not use readily available security measures to limit access between computers on its network and between its computers and the Internet; and
  • failed to employ sufficient measures to detect unauthorized access to personal information or to conduct security investigations.

In English, I think this says that CardSystems stored data they shouldn’t have, deployed apps vulnerable to SQL injection, used brain-dead passwords on internet-facing machines, didn’t use a firewall, and didn’t monitor their DMZ enough.
I see no MS-specific information there. Redmond had nothing to do with this one.
2004-06-24 – America Online
In this case, an AOL employee sold millions of AOL e-mail addresses to spammers. These were obtained by using the credentials of a second, authorized employee.
Again, nothing to do with Microsoft.
2003-03-06 – Data Processors International
Here, the company is mum, and the bad guys got 5 million credit card numbers, but no names. Call this one a “who knows”, since there is so little info.
2006-06-13 – KDDI
I haven’t been able to locate much on this one, but from what I did find, little is known about the source of the leaked data, which included personal (but not financial) information on four million people. No obvious MS tie-in, but nobody can tell.
2005-06-30 – DSW Shoes
According to the FTC, DSW:

  • created unnecessary risks to sensitive information by storing it in multiple files when it no longer had a business need to keep the information;
  • failed to use readily available security measures to limit access to its computer networks through wireless access points on the networks;
  • stored the information in unencrypted files that could be easily accessed using a commonly known user ID and password;
  • failed to limit sufficiently the ability of computers on one in-store network to connect to computers on other in-store and corporate networks; and
  • failed to employ sufficient measures to detect unauthorized access.

Again, these are failures that either have nothing to do with the operating system, or are equally “doable” with all operating systems. No MS-specific issue here.
2006-12-12 – UCLA
I haven’t seen any discussion of the operating systems used. My spider sense tells me this was SQL injection, but this could easily be a case of OS or application patches not being applied, poor configuration by sysadmins (or, to turn it around, idiotic out-of-the-box defaults), etc. Let’s say the jury is still out.
2006-10-24 – Chicago Board of Election
Ah, that toddlin’ town. This was stupid application design (no checks against SQL injection, seemingly), and perhaps more data stored than should have been. Absolutely nothing to do with the vendor, and everything to do with the app dev process.
2005-05-23 – Bank of America / Wachovia
In this one, an illegal collection agency was set up fraudulently obtained information on 670,000 people by buying it from bank insiders:

“Based on forensic examination of Lembo’s computers, it was determined that he had employed upper-level bank employees to access and identify individual accounts in their respective banks,” the police statement said. “That information was then sold to his clients, which included more than 40 law firms and collection agencies.”

Microsoft involvement: zero.
2006-09-08 – Linden Lab . Second Life
These guys got hit by a vuln in a 3rd-party application (reportedly TikiWiki). They also seem to have stored too much in the wrong place.
Again, no Microsoft involvement
Well, that was fun. Let’s recap. Nineteen breaches. The results:

MS blameworthy: 0
MS ruled out: 16
Can't tell: 3

From this evidence, I emphatically do not share Mr. Murphy’s opinion as to either what it will take to improve the data loss situation, or to Microsoft’s role in getting us where we are.
From the evidence I have examined, it would seem to me that poor information storage and handling practices and a reluctance to encrypt are far more blameworthy. Lest I be criticized for my sample, Attrition’s entire dataset is available as a CSV file.
Here’s a prediction of my own. Companies are going to get a handle on the obvious stuff. Encryption will be more widely-used, and unnecessary information will not be stored as thoughtlessly. That will be good news, but it will make things tougher here in EC’s breach analysis division.
In order to understand what causes such leaks, and what we can do to prevent them, we will require better, more detailed information. We’ve discussed this need before. Opinions differ on how to best get that information, and whether those of us who seek it are tilting at windmills, or even whether the value to be gained is worth the effort. As I hope this post helps demonstrate, empirical information trumps FUD, and I want to see more of it in 2007.

6 thoughts on “Let’s look at some data

  1. Good post, Chris. With respect to your own predictions:
    1. I don’t think we’ll see a lot of voluntary encryption unless Congress passes some tough legislation that makes it worth everyone’s while to encrypt, i.e., have tougher notification requirements and penalties for breaches involving unencrypted records; and
    2. I don’t agree with your prediction that unnecessary information will not be stored as thoughtlessly. Indeed, as we see/hear about more huge govt databases that are being shared with localities, I think we’re going to see a worsening of the situation in 2007. I hope you’re right and I’m wrong, but I’m just not optimistic about this.
    Cheers, and HNY,
    /Dissent

  2. I’ll be the first to admit that I have no love for MS, but I’ll agree that Redmond isn’t to blame in most credit card fraud situations.
    It’s the credit card industry in general that’s to blame. They don’t care. Until the industry tightens up their own house, we’re stuck with the situation.
    Tom Mahoney. Director
    Merchant911.org
    Merchants united to protect themselves against fraud

  3. I hear you, Dissent.
    However, the turn of the year brings, if fleetingly, renewed optimism :^)
    At least regarding your point 2, I think the Feds are looking hard at data at rest encryption. According to mailing list traffic, millions of seats are going to be deployed, with product selction now under way. Not sure what the scope is, since my ability to wade through bureaucratese is minimal, but I am somewhat heartened by this directive [pdf] from the White House, and the ensuing acquisitions activity.

  4. Yes, I read about the FDE and mandate. It applies to mobile devices or remote access. It does not seem to apply to the huge databases themselves that are on agency or federal computers that are not intended to leave the premises, which still permits the likelihood of more hacks of govt computers and databases.
    Then, too, we’re talking about the same govt that created a Civil Liberties and Privacy Oversight Board that didn’t even have its first meeting for over a year.
    So maybe the FDE mandate will provide some increased security for federal laptops and mobile devices in the future, but I don’t see this mandate as being anywheres near enough to deal with the potential for more massive federal data breaches.
    And of course, the mandate does not apply to state and local govts who may now be receiving or accessing these huge databases (I’m thinking of the OneDOJ database, for example). So the possibility remains that even with federal laptops supposedly more secured, the data could still be breached by other means.
    Yes, I know, I know, I’m pessimistic. But frankly, my belief in this govt tanked circa 1970, and it’s only been downhill from there. I really would be more hopeful if the 110th Congress actually *did* something to mandate greater security and protection.

  5. re:
    | 2006-12-12 – UCLA
    |
    | I haven’t seen any discussion of the operating systems
    | used. My spider sense tells me this was SQL injection,
    | but this could easily be a case of OS or application
    | patches not being applied, poor configuration by
    | sysadmins (or, to turn it around, idiotic out-of-the-box
    | defaults), etc. Let’s say the jury is still out.
    I do database work involving SSNs/names/etc. for a public university in california, and have not, as of 1/2/07, been able to find any actual facts as to the specific technical vulnerability/flaw that caused the problem at ucla. This may be a good sign. Presumably no one on the IT staff at ucla that actually knows the facts about the technical details of the data breach is authorized to discuss those facts, as doing so would potentially give information to malicious hackers. on the other hand, the lack of detailed public information leaves other database developers/admins in the dark about potential problems with their own data.
    adeu amics!

  6. That’s FUBAR all right. Can’t they fix the damned problems? How are you supposed to fix your systems if they have the same problem?

Comments are closed.