For those who aren’t familiar with it, the phrase “jump the shark” originates with an episode of the American TV series “Happy Days”, where one of the primary characters, Fonzie, literally (at least in the show) jumps over a shark while on water skis. The episode was designed as a desperate attempt to draw in viewers since the overall content of the show had become rather, well, “bleh”. Things were never the same after that episode, and it was generally concluded that once Fonzie “jumped the shark”, the show really had nowhere else to go but up.
But it never did.
About six weeks ago, I reposted a question sent to the Data Loss mail list from an earlier post made over two years prior asking the same question. To date, the replies we have received can be counted on one hand, but the evidence shown at the top of the main DataLossDB page is somewhat clear: for the last several months, we (meaning OSF) have received less reports and have seen less news about breaches involving personally identifying information. One or two people have questioned why, and the answer is simple: we don’t know. We still look for news, we still post what we find, but the decrease in events since the beginning of the year… well, we just don’t know.
Have there actually been fewer events? Has there been a change in the way that events have been reported in the media and through other sources that might disqualify them for inclusion into DataLossDB? Does anyone have any insight into why this apparent trend might be occuring? If so, we would like to hear / read your thoughts. Please mail our curators if you have anything to comment on about this subject.
Posted by Lyger
We recently had an inquiry regarding whether or not we could store more details about certain breaches, specifically the type of Hack (for hacked breaches) that was used, or the application that ended up being breached. Neat ideas, of course, and we’ve considered them ourselves on several occasions, given that we have OSVDB as our sister project. We’ve always wanted to use both, or tie them together, however, we run into some issues in doing so. One big one is that we rarely know the cause of a given breach. That information is simply not disclosed the vast majority of the time. Neither is the application that was exploited, in fact, I can’t recall a single instance of a specific vendor’s product being named in our data set (but I suppose there might be a couple if I looked hard enough).
Adding new fields to the database is a fairly straight-forward thing to do, but, we don’t like to do it unless we can at least somewhat consistently populate these fields. A visitor suggested Primary Sources, so for fun, we searched them.
Querying for “sql injection” yields 21 primary sources results, associated with roughly a dozen unique incidents, give or take. It was more results than I thought we’d have, anyways. But more than anything, it made me wonder what other interesting queries could be made. So, I tried a few:
Querying for “encryption key” had some interesting results where the encryption key had been lost with the encrypted systems/media.
My personal favorite! Querying for “no reason to believe” showed just how cliche that term is in data breach notification letters, returning over 15% of all primary sources.
Querying for “former employee” gives us a glimpse into fraud committed after employment.
Querying for “password protected” shows how common that is used as a “don’t worry” clause in breach notification letters.
Querying for “windows” yielded a few primary sources describing Windows servers that had been breached, but few.
Querying for “database” was also somewhat interesting.
There are likely hundreds of other interesting combinations. The above are just the ones we thought up. Experiment on your own, and if you find anything good let us know.
Many of our “regular” readers are keenly familiar with data breach notification letters. They’ve seen the Primary Sources Archive, or have been unfortunate enough to have the honor of receiving one, or potentially worse, have the unfortunate honor of drafting one. Many, however, have not.Nearly every state in the United States has adopted data breach legislation, and new adoptee-states continue to trickle in each year. Several federal legislative efforts are under way to blanket the nation, and one has even passed pertaining to medical data breaches. Internationally, the issue is also progressing.
Some states, like Massachusetts and Nevada have passed laws, or are in the process of considering legislation governing the implementation of practices to protect personally identifiable information. These requirements are bringing the issue to the people, forcing businesses small and large a-like to consider their security practices, from document disposal and retention periods, to data encryption and fraud prevention. While the effectiveness of these new laws is debatable, there is no question that the laws are forcing the issue to be considered, and that isn’t necessarily a bad thing.
This is where the Primary Sources Archive can really help business of all sizes. We have samples of thousands of data breach notification letters, issued from companies big and small to various states in compliance with law. Wondering how a breach letter should look when sent to Massachusetts? We have hundreds of samples for you — real world examples. Wondering how you should fill out the New York or North Carolina data breach notification forms? We have almost a thousand of those combined. Wondering what type of incidents people are notifying on in Maine? Peruse our collection! You can even find law firms that have specialty in data breach notifications, just by browsing through and seeing what firms are doing work from what companies.
The Primary Sources Archive really is an under-tapped resource for businesses of all sizes, be it the compliance department, the legal counsel, or the small business owner. We’d like to encourage any readers to forward links to the Archive off to their privacy officers, or counsel. You’d be amazed at how useful they may find it.
The trip to Vegas went well, at least as far as 105 degree temperatures, several cab rides, and trips through airport security can go over the course of three or four days (and yes, it took us about a week to recover). Always good to get together with a few friends, meet some new people, and we hope that some of the conference attendees will contact us if they want to help out.
Dave presented a talk at Metricon in Montreal earlier today, and from his phone reports, it sounds like it was a success. We’ll have to wait until he’s back home until we get a complete recap, but he seems happy with the conference overall!
For those asking, we’re still working on Primary Sources and the new legal project… it’s just been a very busy last few weeks for us and we hope to catch up on email and get back to everyone in the next few days. As we mentioned on the mail list, we especially thank Altonius for jumping in and doing excellent work on the Primary Sources project, literally matching dozens of sources to existing incidents and adding dozens of new incidents to the database.
We still have several states to send Freedom of Information requests to, so please check out the Laws page if you might be interested in submitting a Freedom of Information Act (FOIA) request on OSF’s behalf. We’re not done with this yet, and your help would be GREATLY appreciated (we’ve been known to bribe/reward those who volunteer). For more information, please email us at email@example.com.
Posted by Lyger.
The Open Security Foundation and DataLossDB volunteers will once again be in Vegas this year for BlackHat and Defcon. If you are going to be in town and want to get together to discuss the project or anything related to security, vulnerabilities and/or data loss incidents then please contact firstname.lastname@example.org.
We also want to let everyone who has contacted us about the new legal sub-project know that we will be in touch shortly. We are looking forward to formally kicking the project off but have been extremely busy over the past few weeks!
In addition, we want to thank all of our volunteers for their dedication and hard work and also ask that you please take a moment to visit our sponsors page as these organizations continue to support the project.
Hope to see some of you in Las Vegas!
The TD Ameritrade incident of 2007 hasn’t quite been resolved — yet. While the breach may have been contained, the litigation is still ongoing. A class action suit field in California in May of 2007 has reached a preliminary settlement, but the settlement is contested by the individual who filed the class in the first place and has been through some extremely interesting twists and turns.
The case was filed in May of 2007, with a complaint that claimed that TD Ameritrade was essentially selling email addresses of clients to spammers, in violation of TD Ameritrade’s privacy policies and various laws.
A motion for a preliminary injunction kicked things into gear in July 2007, which alleged that the spam was still ongoing, and demanded that TD Ameritrade take steps to protect members of the class (TD Ameritrade customers). The fact that the incident was still ongoing at the time of the injunction was later confirmed in testimony, and it would seem from interpreting the various testimonies in the case that the breach was mitigated “on or about August 14th, 2007”.
Sometime thereafter, TD Ameritrade acknowledged that it had in fact been “hacked”, and that the hacker had access to names and email addresses. During the disclosure (via a letter to customers), TD Ameritrade also acknowledged that the database that had been breached also contained Social Security numbers, but that TD Ameritrade had no evidence that Social Security numbers had been taken. This spawned another lawsuit: Brad Zigler v. TD Ameritrade. The complaint in this new lawsuit went beyond the spam aspect, and brought into view the potential compromise of Social Security numbers as well. In December of 2007, the two cases became officially related.
In early 2008, a new judge was assigned to the case. Several months later, the two cases merged, and a request to have a settlement approved was filed by the plaintiffs (on May 30, 2008). Both sides seemed in agreement at the time. Days later, at a proceeding, that agreement appeared to have dissolved. One of the class representatives, Matthew Elvey, the individual who had originally filed the case in May 2007, opposed the settlement — even though he had signed it days prior. Mr. Elvey stated that he had been threatened, which is why he agreed to sign the settlement. His opposition claimed that the settlement was not fair, that he had been an identity theft victim as a result of the TD Ameritrade breach, and that some of the reasoning behind the decision to settle was flawed. During the same court hearing, one of the most significantly discussed “reasons” for settling was the results of an “organized misuse” analysis, which was done by a third party organization, ID Analytics. This reason was particularly opposed by Mr. Elvey.
Now, before we dig into “organized misuse”, we should first look at how one might assume a traditional investigation into a data breach would proceed. One would suppose that both during and after a breach, an organization experiencing the breach would first try to stop and contain it, try to assess what exactly occurred, and then understand what was accessible, accessed, potentially lost, and confirmed as lost. In containing the breach, one might assume an organization would act swiftly, yet carefully. In assessing the scope, one might think an organization would look to internal security systems to make determinations — networklogs, system logs, audit logs, and transaction logs. An organization might also contract with a firm with forensic expertise to assist in making determinations and provide further analysis. Supposedly, this sort of analysis did occur. The “security officer” responsible at TD Ameritrade, Willliam Edwards, gave a deposition regarding the details of the breach, which became sealed for “attorney’s eyes only”. We can’t conclude much at all from this, however. But back to the hypothetical, what if the aforementioned “expected” protocol didn’t provide sufficient information, or perhaps didn’t provide “ideal” conclusions? More alternatively, what if those conclusions did not give the organization the answer it wanted to hear?
Fortunately, there’s another option: a now nearly court-proven way to gain intelligence into the matter… in comes an “organized misuse” analysis. Companies, with what appears to be access to and/or partnerships with credit bureaus, can run some form of pattern analysis to determine whether or not identity theft is linked with a given organization, population, or sample. Presumably, they analyze occurrences of ID thefts in a sample, and determine whether or not the samples show a higher occurrence of ID theft than a baseline sample/population (no doubt via some fancy math and other complicated stuff.)
Where this all gets interesting is that when the TD Ameritrade incident was originally disclosed, there was no mention of Social Security numbers being affected. OSF did not include it as a data type, nor did we find any indication in any reports regarding the incident that they had been included. In the process of fighting this class action suit, however, TD Ameritrade used an outside firm to run this “organized misuse” analysis, which came back as “negative”. TD Ameritrade could have simply said that Social Security numbers were not accessible, but they didn’t, which would imply that they were indeed accessible to the intruders. Nowhere in any of the documents we reviewed did we find any denial of this, and in fact, in many instances they confirmed that “Social Security numbers were in the database”.
That statement is very different from TD Ameritrade *outright* saying that Social Security numbers were accessible. It could have been that the nature of the compromise exposed a database view, and that Social Security numbers were not accessible to that view. Had that been the case, saying that they were not accessible seems like a stronger defense than going through an expensive “organized misuse” analysis process. It would seem evident that proving there were logical or physical gates in place that separated the data, and thus made it inaccessible, would have been a less expensive and more convincing an argument to make, but no actual attempt was made to refute accessibility. From that, it does not seem a far stretch to assume that the numbers were accessible.
Even still, it seems that relying on “organized misuse” analytics as some sort of “proof” that a breach of Social Security numbers did not occur is a bit curious, and also possibly a logical fallacy. For one, it would only be reliable at the point in time when it was concluded, and actually might only be representative of a point in time months prior given the delay with which credit data is populated. It could never definitively conclude that a breach of identities did not occur, given that there could simply be the case that the stolen identities hadn’t been sold or otherwise abused at the time of the analysis. Given the permanent nature of identities and specifically, Social Security numbers, it also does not seem implausible that an identity thief might “hold on” to their find for some duration prior to capitalizing on it as a way of “laundering” the identities. Granted, this is speculative, but so is the presumption that since no evidence of “organized misuse” exists, Social Security numbers had not been compromised.
Regardless, the settlement would have essentially consisted of the following:
- TD Ameritrade would post notices 4 times in the year, for 1 week each, regarding the incident.
- Members of the class would get a free 1 year subscription for Trend Micro Internet Security Pro (retail value $69.96). The software was to address the spam that came as a result of the disclosure of TD Ameritrade customers’ email addresses.
- TD Ameritrade would commit to twice yearly external penetration testing.
- TD Ameritrade would perform account seeding to detect compromise of email accounts.
- Class members would give up their right to form another class action lawsuit, but could pursue TD Ameritrade as individuals if identity theft did occur as a result of the breach.
- TD Ameritrade would donate $20,000 to the Honeynet Project, and $35,000 to the National Cyber Forensics and Training Alliance.
- TD Ameritrade would cover all legal expenses of the case incurred by the class.
- A settlement notice would be posted in USA Today.
Elvey retained additional counsel to oppose the settlement that he and his original counsel had signed. Over the course of several months, and several court appearances, the plaintiff and the defendant seemed to “buddy up” to some degree, while Elvey continued to oppose with his new representation. Elvey had all but seemed discredited when, in late 2008, the Texas Attorney General jumped in on behalf of a stated near half-million Texans represented in the class. The Texas AG had the following to say (as summarized by the judge):
- the proposed settlement agreement offered “no meaningful relief to the class members”;
- the award of proposed fees to class counsel was excessive;
- the proposed settlement failed to address the harm of identity theft adequately;
- the proposed release was too broad;
- The Texas Attorney General contended that the settlement was essentially worthless because the “warning” to be placed on the TD Ameritrade website would largely go unseen by consumers most vulnerable to stock spam;
- the security measures TD Ameritrade agreed to conduct should have been conducted by “any reputable company” anyway;
- the coupon for security software was of little value because similar software was largely available to most Internet users for free or at low cost;
- the Texas Attorney General noted that the class members were to receive no monetary recovery while the proposed attorney fee award for class counsel was substantial —— $1.87 million;
- the proposed settlement agreement did not address adequately the potential harm to class members from identity theft;
- the Texas Attorney General further argued that the settlement agreement should make clear that the individuals who engaged in the unauthorized access are not “Released Parties” and “Releasing Parties” should be amended to make clear that government entities such as the Texas Attorney General has not released any claims to relief related to this security breach;
These oppositions were strong, and spun off months of additional negotiations between the plaintiff, the defendant, and the Texas AG’s office. The revamped settlement, which won the approval of the Texas AG, was a slightly improved version. It emphasized somewhat more the risk of ID theft from the breach, and also removed or revamped some of the limits that class members would have had imposed on them for additional suits, but substantively didn’t really alter much.
What it did change was that it created a new argument for the defendant and the plaintiff: “The Texas AG signed off…”, which sealed the deal and seemed to outweigh any opposition to the settlement by Mr. Elvey. The revised settlement was “preliminarily approved”, on May 1st, 2009, bringing the class action suit a big leap forward towards conclusion.
In all, this is a fascinating case, which begs several questions: why is this “organized misuse” so convincing? What is so confidential about the deposition given by Mr. Edwards? It was sealed for several reasons, some of which seem a little far fetched. One was that it might expose the class to the risk of identity theft, and that was vaguely related to the fear that such information, if made public, would somehow entice or encourage hackers to go after TD Ameritrade. This doesn’t seem all that realistic. The firm has a million reasons to be concerned about security, but, other aspects of the case suggest that this “concern” is a recent phenomenon at TD Ameritrade, for instance: How exactly is a commitment to perform “twice yearly independent vulnerability scans” a benefit to the class? Is TD Ameritrade not already required by industry standards like PCI, or better yet, its own internal security policies to do so? Was this not point 6 of the Texas AG’s argument? And why did the Texas AG back down on several points?
And those are just the questions on one side of the coin. Why did Elvey approve the settlement in the first place? The “threats” claimed could use some additional scrutiny. Had he not signed the settlement, would things have gone much differently? Did Elvey’s “late game” claims of identity theft help or hurt his case?
We don’t yet have all the final numbers on this, as the case is still ongoing, but when we do we’ll update the incident with the final costs associated with this class action suit. The costs will be of some substance, but from the looks of it, a very small amount per record breached. We are updating the data types to include Social Security numbers, partially because of a recent article in the media on the topic, and partially due to the information gathered from the court documents. All the documents we’ve collected regarding this case are available for your perusal here.
- Elvey V. TD AmeriTrade – May 31, 2007 – Complaint
- Elvey V. TD AmeriTrade – June 28, 2007 – Amended Complaint
- Elvey V. TD AmeriTrade – August 14,2007 – Motion for Preliminary Injunction
- Zigler v. TD AmeriTrade – September 21, 2007 – Complaint
- Elvey V. TD AmeriTrade -JUNE 12, 2008 – TRANSCRIPT OF PROCEEDINGS
- Elvey V. TD AmeriTrade – SEPTEMBER 15, 2008 – TRANSCRIPT OF PROCEEDINGS
- Elvey V. TD AmeriTrade – OCTOBER 7, 2008 – TRANSCRIPT OF PROCEEDINGS
- Elvey V. TD AmeriTrade – MAY 1, 2009 – Preliminary Approval of Settlement
We believe gaining legal insight and costs associated with data loss incidents are key indicators to help fully understand the true impacts. We are in the process of starting a new legal sub-project that will be tightly integrated into DataLossDB. The project will focus on collecting information on lawsuits associated with data loss incidents. The goal is to be able to provide more depth to the data, give us some editorial fodder, and most importantly, to get some empirical data on the legal costs of a data loss incident. If you are interested in helping to lead, shape, and ultimately maintain this project please contact email@example.com.
It appears that Capital One has announced a new program for helping non-profit organizations to raise funds (see picture). According to the plan, all rewards earned on these cards, including one percent of net purchases and an additional $25 with the first purchase, go directly to support the affiliated nonprofit organization. As a 501(c)(3), OSF is wondering if anyone might be interested in obtaining a DataLossDB Capital One card to make donating easier (and to help the economy!). We’re also accepting other ideas for card designs, such as “CHECK ID” on the front (thanks, Sullo!). Please contact us if this idea interests you or if you have any suggestions.
Also, we would like to announce that BreachCenter.com is now online. Intersections Inc. has partnered with Financial Services Roundtable and ITAC, the Identity Theft Assistance Center, to provide this service, and OSF is contributing information on recent data breaches to the site. BreachCenter.com also features news and opinions from the ITAC blog. Please check them out when you can.
Lastly, T-Mobile has been in the news recently regarding an apparent data breach, which may or may not have involved its customers’ personal information. According toUSA Today, “The document ‘copied’ by the hacker Pwnmobile did not get into his hands via a hack, the company says. Information in the document is legitimate T-Mobile data, but is not customer information. Investigators can’t yet say for certain how Pwnmobile got his mitts on a copy of the document.” So while details are still sketchy, we’re following the story and will post information to the DataLoss Mail List as it becomes available.
More news to follow later in the week!
Posted by Lyger.
In early April, Open Security Foundation came up with an idea for a new contest for DataLossDB. OSF had done something similar for our sister project, the Open Source Vulnerability Database (OSVDB) a few years back: an “oldest vulnerability contest”; this time, we decided to bring the same type of contest to DataLossDB. We lined up some great sponsors, and held high hopes that contestants would be reaching down into the 90’s for data loss incidents, striving to win one of the excellent prizes kindly donated by our sponsors.
On May 1, we kicked off the contest, announced it to the masses, and in they flooded. It started off encouraging but quickly went well beyond that. We watched as the dates of the submissions went further and further back in time. Some submissions were clearly humorous, such as “Eve was socially engineered by a serpent resulting in total loss of records and denial of service attack against the tree of knowledge; The computer involved was an apple.”, or the biblical tenth and final plague of Egypt, to name just a couple. Unfortunately, we can’t find any way that we can possibly include them in the data set, but they made for a good chuckle.
There were others that were much more legitimate, but which don’t really “fit” into the DataLossDB data set, such as the “loss” of public records. Government ledgers and similar records are hard to include given that the information is freely available for public inspection, such as this loss of accounting data, or this loss of town files. Good stuff, but not really threatening to personally identifiable information (which isn’t normally exposed). Other submissions were somewhat difficult to determine what, in fact, was exposed, like this 1887 New York Times article regarding service members’ pension records. OSF’s “curators” had to do some homework on that particular submission to determine what exactly was in a pension record at the time, and we came up with nothing of a conlusive sensitive nature (keep in mind that no Social Security program existed at that time.) Most of the sample records we found contained name, rank, and years served, and most didn’t even include a home address. While we liked this submission, we couldn’t accept it — it was too vague. If an entry were to qualify to win the contest or any prize, it had to be more definitive. There were other similar entries as well, such as the 1889 New York Times article regarding the loss of a Union’s meeting minutes book and their expense books. It would be a stretch to assume that there was PII contained in either of those.
Multiple contestants submitted the “most misused social security number of all time” story, regarding a wallet manufacturer who placed a social security card “look-a-like” in wallets they sold which happened to contain the Social Security number of a vice president’s secretary, Mrs. Hilda Schrader Whitcher. Reportedly, by 1943, thousands of people were using her Social Security number as their own. A data loss incident, no doubt, but number affected is less than 10, which unfortunately made it ineligible for the competition and not a fit for the data set. There was also a great submission regarding a card embosser who printed and used 3,000 fake Diner’s Club cards. A great story of credit card fraud, but not one that threatens identities, and thus not something we’d really include in the data set. The numbers were fake, as were the names.
We had several other decent submissions that we couldn’t accept as well, such as a 1998 incident where CBS SportsLine exposed information regarding thousands of March Madness contestants on their website, or the WRGT Fox 45 breach of 1999 where names, addresses, and email addresses were exposed on their website in a text file. The information wouldn’t qualify as PII (most of the information would be considered “telephone book material”), but it was interesting to see late 1990’s security breaches.
All of the entries listed above were fascinating submissions in one way or another, but didn’t make the cut for inclusion in the database, and thus didn’t make the cut for winning prizes. Most entries DID, however, make the cut… and without further ado…
In third place, we have both an oldie and a biggie. This one not only wins a prize in the contest, but also earns a spot (2nd place) on the DataLossDB top 10 breaches of all time list. “Dissent” from databreaches.net uncovered and submitted the 1984 TRW incident, where computer hackers gained access to a system holding credit histories of some 90 million people. The data included information on employment records, loans, Social Security numbers, and more. Congrats “Dissent”, great submission.
In second place, we have a 1983 submission from “midnitrcr” regarding the Memorial Sloan-Kettering Cancer Center in New York, where a Time Magazine article reports that hackers had broken into a “Digital VAX 11/780 computer, which monitors the radiation treatment for 250 patients”, and had gained access to billing records, and inherently medical treatment information. This all occurred on the heels of the “War Games” movie being released, and as Time Magazine pointed out at the time, posed “a serious question: How to safeguard information stored inside computers?”. Again, a great submission, and kudos to “midnitrcr”.
And in first place, we have two submissions from Corey J Chandler (AKA “Sorthum”), both of which qualify, and both of which are rather old. The first is a 1953 incidentreferenced in a New York Times article. This is another case of Union books being stolen, but unlike the 19th century examples, this one included names, addresses, and importantly, Social Security numbers of 700 union members. This is officially the oldest theft of Social Security numbers that we have seen that meet our criteria for inclusion in the database. Congrats Corey! Not to be outdone by a simple mid century incident, “Sorthum” also posted another qualifying incident. This one is referenced in a 1903 Los Angeles Times article, where the dispensary records for the Southern California Hospital for the Insane went missing, and were through to be stolen (or “purloined” as the LA Times put it) by ex-Steward C.N. Whitaker and former druggist, Fred W. Howard. Dispensary records would have included patients’ names, and at least information pertaining to their prescriptions. Information that, if a hospital or drug store lost today, would clearly qualify for an entry in DataLossDB. The records lost covered “the years 1896 to 1901 inclusive”, and Dr. M. B. Cambell, the hospital’s medical supervisor, was “confident” that the records would be recovered. We have no information as to whether or not they were. Anyone feel like doing more digging?
Some non-winning contestants submitted dozens of quality incidents to be included, such as “SYNACK3”, “spacerog”, and “jjturner”. These three individuals pulled in dozens of quality submissions. “jjturner” found a treasure trove of Canadian data loss incidents inside their Privacy Commisioner’s “Annual Reports to Parliament”, whichwww.priv.gc.ca has posted as PDF’s on their website going back to the early 1980’s. These reports were fascinating to read, as they highlight some initial and early awareness of the threats imposed by computers and computer networks to privacy in one of the most unlikely of places: a federal government. Hats off Canada, eh.
“spacerog” found a 1998 incident that was the most “ChoicePoint-esque” incident we’d seen (only considerably older) where employees at the Social Security Administration sold 20,000 Social Security numbers to West African credit card thieves. One of our OSVDB moderators, “cji” submitted several great incidents, even though he technically couldn’t qualify for prizes. One of them actually would have won him second place! It would have also won the “Least Sexy Submission” award — which we think we’ll give him anyways. We would summarize the breach, reported in a 1957 Chicago Daily Tribune article, but we might fall asleep re-reading it. Instead: “The case involved the looting of employment and wage information on persons not on the relief rolls from the 4 million wage record cards of the state labor department. The stolen information, sold at 50 cents a name to the operator collection agency, was obtained by a frauds unit employee.”
Some submissions came full circle, such as the 1998 submission by “SYNACK3” regarding a computer hacker who was jailed for 18 months after getting caught stealing over 1,200 credit card numbers from Ausnet. This incident is particularly amusing to us considering one of our very own, “Jericho”, posted it to the ISN mailing list some 11 years ago!
Congratulations to the winners and all the contestants. You’ll all be receiving various “stuff” in the mail shortly. A special thanks to our sponsors as well (CREDANT, Arcsight, AON TechShield, StrikeForce Technologies, Inc., ITAC Sentinel) for donating the great “stuff” we’ll be mailing out, as well as supporting the endeavor and making quick commitments on really short notice. The contest wouldn’t have been much of a contest without our sponsors, so please check out their sites as well!
Also, we *might* launch another contest this year, provided we can find the time after changing every mention of “Stolen” in the database to “Purloined”.
Chris Walsh recently sent us roughly 190 PDF’s, obtained from the state of New York (for free, thank you kindly New York!), covering what appears to be most of the breaches reported to New York during 2008. Many of these seem familiar, some not. We’ll be processing these over the course of the next few weeks, and we’ll highlight anything that stands out, as usual. They are uploaded and on the site in the NY primary sources section for your perusal.
In addition, the contest for the Oldest Data Loss incident is winding down! Get your submissions in before the deadline (May 15th). There are some awesome prizes donated by our excellent sponsors.
Lastly, we recently attended the 2009 SC Magazine Awards, where we had the opportunity to meet some great people, have a wonderful dinner, and win the editor’s choice award! Thank you kindly SC Magazine. The experience was great, and the credit highly appreciated. A big “Thank You” to all who have contributed to OSF projects over the past several years. Last, but not least, a big “Thank You” to our sponsors who have helped make all this possible.
Posted by d2d.
We knew when we started the Primary Sources Archive that we’d find some interesting incidents. There was little doubt that what we were seeing reported in the media was a fraction of what was really going on, and we continue to feel that even what we find in the media, and primary sources, still represents a fraction of what really goes on. We did not exactly anticipate finding enormous un-reported breaches via primary sources, however.
We recently launched a small initiative to get primary sources via volunteer contributors from across the 50 states. One volunteer recently submitted a batch of files to us, obtained through a FOIA equivalent request to the state of Illinois. Of those, most were incidents we already knew about, with some exceptions, and one rather large exception.
It would seem that Walmart experienced a significant breach in mid-2007 that we had never heard of in the media. A former employee left Walmart with personnel data of over 48,000 Walmart associates residing in the state of Illinois. That is an enormous number of records for just one state.
In reading the language of the document obtained, it would seem that the breach wasn’t exclusively affecting residents of Illinois, leading us to ask, who else was affected, and why haven’t we seen this elsewhere? If we make the assumption that the breach was nationwide, then it may have affected over a million people. Considering Walmart employs 1.8 million people, the numbers aren’t terribly off.
- Number Affected in Illinois * Population of the USA / Population of Illinois = Number Affected in USA
- 48,000 * 300,000,000 / 12,852,548 = 1,120,400
That assumes that the breach isn’t localized, and that population is a reliable metric for measuring data loss incidents, neither of which is known. Regardless, this is a significant breach, and we never heard of it until now.
We have several FOIA equivalent requests out for data during that timeframe which may shed more light on the incident, but we found it interesting enough to post now.
As an aside, and while on the topic of older breaches, the Oldest Data Loss Incidents contest is still underway. We have great prizes available, so be sure to compete!
Posted by d2d