Since the database’s inception, we have added incidents based on specific criteria and omitted incidents that didn’t quite fit that criteria. The criteria has traditionally been:
- An incident must have lost one or more of the following data types:
- Social Security or national ID number
- Credit card number
- Bank account number
- Medical record
- Financial account number
- AND the number of records lost/stolen/missing must be greater than 10,
- AND the data lost must have had a steward organization.
The last point is often a point of confusion. For instance, three gas stations in a town attacked by skimmers fall into a grey area, and wouldn’t normally be added to the database, as there is no cut and dry identifiable steward; we can’t place responsibility for the loss on any one entity with full confidence. You could blame the gas stations themselves for not having safeguards, but the responsibility falls in a grey area in terms of applicable prevention. If it turned out that an employee installed the skimmers, then it would fit our criteria and would be cataloged as an incidence of Fraud/Social Engineering. A laptop stolen out of a car, however, is the responsibility of the owner of the laptop to safeguard it. There really is no grey area, as there is an entire industry built around guarding portable devices, and laws in place around the world designating owner responsibility.
Our criteria has helped us keep a consistent, relevant data-set. On the other hand, our criteria has also forced us to reject interesting and possibly relevant incidents; incidents that many who follow the project would probably want to know about. The criteria has also made us prone to many internal debates, and occasional arguments over applicability. One thing we mostly agree on, however, is that doing nothing with these incidents that we and our volunteers have drudged up is a waste of energy. We want to keep that data, but not necessarily have these ‘fringe’ incidents impact charts and graphs generated on the website or impact user-derived statistics generated via downloads of the data-set.
As a result, we’ve decided to create a new category of incidents: “Fringe” incidents. You won’t see these fringe incidents in a search unless you specifically check the box to see them. They won’t show up in our statistics graphs or our reports, and they won’t be in most data exports. Instead, we’ll make separate data exports if you want to see that data. We’ll still tweet these fringe incidents as they tend to be of some interest to followers.
Examples of “Fringe” incidents might include data loss incidents with fewer than 10 people affected, or data loss incidents where the data type might be more or less directory (name, address, phone number) information.
Some incidents currently in the database are likely to be moved over to fringe since we have on occasion bypassed our own criteria when a particular incident seemed egregious enough. We will no longer have to do that going forward, which should facilitate moderation of user submissions (since we won’t have to agonize over saying ‘no’ as much as we used to).
We’ll be clearing out our queue over the next few days and adding more incidents as ‘Fringe’. Here are some links related to this endeavor: