Now being reported in the mainstream media, JCPenney was “Company A” in the recently infamous Albert Gonzalez trial. In court filings, we found some attachments that seem to have been a convincing factor in the judges decision to unseal the identity of “Company A”, a.k.a JCPenney. JCP fought hard to keep its identity concealed, but ultimately it would seem that these attachments, as well as some reporting by Evan Schuman made the difference.
Attachment A, filed in document 14 of the case (for those following the case on PACER, etc.), shows ICQ chat extracts where Gonzalez and a co-conspirator discuss JCPenney. It is damning from a security professionals point of view. It would seem almost irrefutable that JCPenney was compromised. How many cards were stolen are unknown, but cards were almost undoubtedly stolen and JCPenney has (until now) seemingly dodged a huge public relations bullet. Below is a snippet from the attachment:
- Gonzalez: “what did hacker 2 say about jcp?”
- Conspirator: “he hacked 100+ sqls inside and stopped”
- Gonzalez: “hacker 2 told me he found a place to snif for dumps in jcp”
- Gonzalez: “i see, hacker 2 showed you anything?”
Gonzalez then posts what appears to be names and credit card details (redacted in the court docs). They then go on to talk about how one of the conspirators had “domain admin” access, suggesting that they pretty much had control of everything in the given network (depending on topology and segregation).
We struggled with a possible JCPenney incident before reading this document. We initially categorized it as “fringe”, but it seems pretty obvious at this point that JCPenney was either:
- 1) just hacked
- 2) hacked badly enough to expose card data
But judge for yourself: here’s the attachment and the full pdf we obtained (including the attachment) for context. If you use these, please credit the Open Security Foundation for buying these and making them public — you don’t have to as they are public record, but we did have to pay for them, so we’d appreciate the credit!
I’m going to have to apologize in advance for the extreme use of ellipses here. I’m frankly confused as can be over this blog post, and the result is aggressive punctuation.
In what seems to be one of the most ridiculous situations we’ve read about recently, the Richmond Times reports that a U.S. District Court judge has ruled that a woman posting Social Security numbers of government workers online was, well… *cough*… *pains me to type this*…protected by the First Amendment. Yes… posting PII online is protected by the First Amendment. The judge ordered the state of Virginia to halt prosecution against her for doing so. The state has appealed, and a three judge panel is reviewing the appeal.
This is only part of the ridiculousness. This Virginia woman is essentially doing this in protest to how accessible Virginia residents’ personal information is via public records stored by various clerks around the state (mortgages, divorce decrees, etc). Most (if not all) of these records she’s referring to are obtainable by anyone in unredacted form, online in some cases or in person in most cases. In a way, we’re rooting for her…
Isn’t a ruling like this a bit counterproductive? Having a court rule that posting PII online is protected as freedom of speech is… well… very bad for data loss! We’re not questioning the ruling, really; it may make sense. It does, however, seem (on some level)… well… really *expletive*’ing messed up.
On the one hand, you have laws being made and enforced to protect that sort of data, and on the other hand you have judges throwing around the First Amendment. Maybe, just maybe, if governments didn’t exempt themselves from these breach notification laws, we’d be in better shape! Virginia’s data breach law exempts government PII in this paragraph:
“The term does not include information that is lawfully obtained from publicly available information, or from federal, state, or local government records lawfully made available to the general public.”
It seems hypocritical of the State of Virginia to go after anyone about posting PII online when the government freely does the same thing. Virginia isn’t the only state exempting themselves, either — many are. Maybe we should tabulate a list of ’em?
Share your thoughts with us on our discussion mailing list.
Written by d2d
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: