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:
The Open Security Foundation (OSF) is an internationally recognized 501(c)(3) non-profit public organization seeking senior leaders capable of providing broad-based perspective on information security, business management and fundraising to volunteer for an Advisory Board. The Advisory Board will provide insight and guidance when developing future plans, an open forum for reviewing community feedback and a broader view when prioritizing potential new services.
OSF was founded in 2004 and has been operated by information security enthusiasts since its inception. We exist to empower all types of organizations by providing knowledge and resources so that they may properly protect, detect and mitigate information security risks. We believe that security information and services should be easily accessible for all who have the need for such information. We promote open collaboration between companies and individuals, provide unbiased information to uphold educated decision-making, and attempt to eliminate the need for redundant works while striving to improve organizations’ overall security posture.
Prospective Advisory Board members should show an ability and willingness to:
-Participate actively in all meetings of the Advisory Board (2 times per year and as otherwise needed)
-Represent OSF and its mission to organizations and the general public
-Review and provide feedback for proposed OSF plans
-Chair and serve as members of committees
-Assist in locating and developing funding sources for OSF
If you are interested in volunteering please email us at firstname.lastname@example.org and provide the following information:
Area of Expertise:
If you know someone with senior leader experience who you believe could act in an advisory position please contact us at email@example.com.
The call for Advisory Board volunteers will be open until March 19, 2010. We will review all submissions by March 31, 2010.
The Open Security Foundation (OSF) has grown from a humble beginning in 2004 to an internationally recognized 501(c)(3) non-profit public organization. Through the work of a small team of dedicated information security enthusiasts, the Open Source Vulnerability Database (OSVDB) and DataLossDB projects have provided organizations of all sizes with the knowledge and resources to accurately detect, protect and mitigate information security risks. OSF research is often cited throughout the security industry and the organization was honored by being named winner of the SC Magazine’s Editors Choice award for 2009.
To ensure the highest quality information that has become the trademark of OSF, a tremendous amount of effort is expended on a daily basis by OSF volunteers to process an ever increasing amount of data loss and vulnerability reports. Over the years, many volunteers have been involved in the projects, but for the most part the the heavy lifting has been the work of only a few very dedicated volunteers. The “open source” approach to resourcing the projects has been successful to date but is now proving to be an unsustainable model. With long-term sustainability and increased services as our goal, we have initiated a comprehensive review of our current operations, our existing approach to project funding and the creation of potential new services for the security community.
As a start, we plan to do a better job of sharing our view on the state of the information security industry and creating a mechanism to gain community feedback to better establish our vision for the OSVDB and DataLossDB projects.
To that end I want to take a moment to share our initial plans for 2010.
The OSF officers and project leads have been dedicated to the daily operations required to make OSVDB and DataLossDB the recognized leader in vulnerability and data loss tracking. This focused dedication has left little time to take the pulse of the industry as it relates to our projects or to establish a clear long-term vision for the projects. To address this need, OSF will be creating an Advisory Board. The board will consist of three to five senior leaders capable of providing broad based perspective on information security, business management and fundraising. It is our hope that this will provide a sounding board when developing future plans, an open forum when reviewing community feedback and a broader view when prioritizing potential new services. Additional information along with an official call for Advisory Board nominations is planned for 2/12/2010.
Direct unfiltered feedback from both the security community as well as the organizations that benefit from our projects is critical. Over the next few weeks, we plan to post a public survey asking for feedback that will help shape our long-term vision and establish our near-term plans for OSVDB and DataLossDB. Those of you who value the work that the OSF provides and/or consider yourselves friends and supporters of OSF are asked to help spread the word to maximize the feedback provided.
Feedback from the survey will be the foundation for the OSF vision and 2010 plan. Our goal is to present a draft of both the vision and the 2010 plan to the newly formed Advisory Board by mid-April 2010. Once finalized, both documents will be shared with the information security community.
OSF has been recognized for providing a critical service to the information security community but our potential is much greater. We look forward to hearing your ideas on how OSF can further improve the state of security while building a stronger organization to deliver even higher quality research and additional services.
Chairman, Open Security Foundation
Where on earth did the breach go? We’ve asked ourselves, we’ve asked others, and we’ve been asked by many.
The simple answer is, we don’t know! It could be anything, really, that has caused the dramatic decline in reported data loss incidents in 2009. Here are a few ideas:
- The decline is media related. Data breaches are ‘passé’.
- Organizations are implementing better security.
- Organizations aren’t reporting incidents.
- Solar Flares
None of these, with the exception of solar flares, is likely to be analyzable at first glance. But what about the first bullet?
Due to a lack in expertise of space weather, we decided to dive into the Google News archives, and things became interesting. Google News’ timeline feature facilitates this kind of analysis. We looked through search result totals matching the query “data breach”, per month, for 72 months (2004 through 2009). We then tossed the data into a graph, added a polynomial trend-line with an order of 6, and took a deep breath.
Posted by d2d
What does the coffee shop, the mall, the discount super center, the grocery store, the post office, the laundromat, and your favorite local restaurant have in common?
Aside from a fundamental desire to part you from your money, they also are a common stopping point on the way home from work, or while out shopping. This week and next, think about your data while you get that double mocha latte, or run in for a last-minute holiday gift. Leave the laptop someplace safe (not in the back seat of your car), lest you want to ring in the new year with your company in the headlines. Better yet, don’t store anything sensitive on it to begin with. New Years resolution in the making, perhaps?
Several data loss incidents occurred this year and last over the holidays, and there are reports that Santa’s naughty/nice list may have been compromised. This suggests that the holidays are indeed a chaotic time, and that chaos can desensitize you to the value of the data you may be carrying, or leaving behind (understandably). Unfortunately, there are no “I forgot cousin Eddy was coming and needed that last minute gift…” exemptions in the various data breach laws. These holiday incidents also shows us that thieves enjoy our “vacation”, and celebrate the holidays by breaking into our offices! So keep that in mind as well when you leave work this week.
And last, if you’ve already filled the stockings, and bought everything you need for the holidays, and happen to have a few dollars left over, consider a donation to OSF to keep these projects running.
Happy Holidays and Such,
The DataLossDB Team
Posted by d2d
They often find them, and usually get a complimentary legal threat or outright lawsuit to go with it.
Recently, a Minnesota Public Radio reporter went digging, and indeed found records exposed. The records in question were I-9 processing forms held by Texas-based Lookout Services. The undisputed truth seems to end about there. The reporter wrote about the incident, and the attention the incident stirred caused the entire state of Minnesota to stop using Lookout Services for I-9 verification. Lookout Services responded with a lawsuit, essentially claiming that MPR illegally accessed the data.
Now, MPR claims it didn’t need to authenticate in order to access the data. Lookout Services supposedly disagrees, according to a great article by minnpost.com reporter David Brauer, which gives excellent background into the issue. My interpretation is this: an authenticated connection was used to find a URL that granted access to data without authentication. For instance, most modern web applications determine if a login session is established on every request to the website. It is possible to ‘omit’ or ‘forget’ to check on certain requests, and just hand the content over. If I had to bet, I’d bet that the reporter found such an omission, then ran with it.
Was it illegal to do so, if that indeed is what happened? Maybe! Which is why reporters should really tread carefully when trying to ‘create news’.
This isn’t a recent phenomenon either.
In October of 2008, a WHRW campus news reporter, while reportedly walking through campus, stumbled upon an unlocked room with the door taped open. The room reportedly contained thousands of student records. The reporter announced the “breach” on the radio and blogged about it. The University then began a criminal investigation, which involved the district attorney, per this reporting:
The room was apparently several feet off the ground on a maintenance catwalk, and the reporter didn’t simply ‘stumble upon’ it. Was it a ‘good thing’ that this data storage issue was brought to light? Maybe, but was it done properly? We didn’t even add this incident to the database, although the option to do so isn’t exactly off the table.
Sometimes these things go without bickering between the reporter and the breached entity, but usually only when the breach was wide open and it is clear that the reporter did indeed just happen to stumble upon it.
Searching for data breaches isn’t something we at OSF have ever really condoned. It falls in a grey area for certain. Even using search engines to find the data, such as utilizing public resources to find publicly accessible data, is somewhat questionable as the act itself mirrors what an ID thief would do.
Yesterday, for the first time ever, a data breach notification bill actually came to a vote in the United States Congress. The House of Representatives passed by voice vote H.R. 2221, the Data Accountability and Trust Act. This bill and others have been introduced many times over the past several sessions of Congress, but unlike other similar bills and this bills’ predecessors, H.R. 2221 not only came out of committee, but was voted on and passed.
This bill is similar in nature to multiple state breach notification laws that have already been passed. Here are some highlights:
H.R. 2221 defines personal information as, “an individual’s first name or initial and last name, or address, or phone number, in combination with any 1 or more of the following data elements for that individual:
- (i) Social Security number
- (ii) Driver’s license number or other State identification number
- (iii) Financial account number, or credit or debit card number, and any required security code, access code, or password that is necessary to permit access to an individual’s financial account.”
Some more details include:
- The Federal Trade Commission would be the responsible agency.
- The FTC would ultimately define the proper technical procedures for protecting data.
- Organizations that have data need to establish a data security policy.
- Organizations must identify an information security officer.
- Organizations must have a process for identifying vulnerabilities, and monitoring for breaches.
- Organizations need a process for securely destroying data that is no longer required.
- Breaches need to be reported to the consumers affected, and the FTC, unless:
- “there is no reasonable risk of identity theft, fraud, or other unlawful conduct.”, which will be defined by the FTC should the bill pass.
- The organization experiencing the breach does not fall under the jurisdiction of the FTC.
The jurisdiction point is significant. The FTC does not have the power to enforce regulations on government, banks, savings and loan institutions, the insurance industry, and non-profits, which include colleges and universities. These limitations seem significant.
The bill has some more stringent requirements for “data brokers”, including audits in the event of a breach. It also requires two years of quarterly credit reports provided to victims at no charge. Third parties are required to notify customers in the event of a breach, and the actual owner of the data is then required to notify consumers. There is an encryption exemption (in addition to whatever exemptions the FTC will define) should the bill become law. The FTC would also be tasked with posting breaches on their website if the commission deems it in the public interest on a case-by-case basis.
There are several other interesting subtleties in this bill, and we encourage anyone interested to read the bill themselves. The law has some gaping holes, such as FTC jurisdiction, and may preempt stronger state laws. On the flip side, it would certainly add some degree of consistency for organizations experiencing breaches, and would simplify compliance as a result. It also would provide notification for consumers in states without breach notification laws. For these reasons and many more, it behooves everyone to familiarize yourselves with this particular proposed legislation.
Updated (12-10-2009): See Incidents that may have been exempt from this bill were it law at the time of the incidents.
Finally, below is a clip of the bill being explained in the House, and subsequently passing by voice vote:
On occasion, we look for news related to things other than data loss events. Press releases veiled as “news” are a frequent treasure chest of (not so) great information, so we often use detailed and complicated techniques to make sure we have as much information as we can gather about… Open Security Foundation and DataLossDB. In other words, YES, WE GOOGLE OURSELVES. Oh, don’t be shocked. You “ego surf” yourselves too. Admit it.
The Sixth Annual Gibbs Golden Turkey Awards – “According to the Open Security Foundation’s excellent DatalossDB Web site” – we appreciate that, and Mark did write “according to… web site.” Best one we’ve seen so far.
Config Errors Leaving Huge Security Holes: Study – “According to the Open Security Foundation, so far this year 37 organizations have lost almost 132 million sensitive records through external hacks as a result of sloppy or poorly secured network IP configurations.” – well, kinda. Our *statistics*, when gathered and analyzed, might *infer* something related to that conclusion, but we (meaning OSF) were never asked to make a statement about any number of records compromised through any particular attack vector.
IP Networks Are Vulnerable Due to Lapses in Security, Compliance and Proper Configuration, Says Telcordia – Calvin, meet Larry. Larry, meet Calvin. Your stories both use OSF and DataLossDB as a resource, but we don’t remember receiving a call or even an email asking us for comments, clarification, or any other additional insight for background. You, sirs, have an uncanny gift for being able to use each others words IN THE EXACT SAME WAY. That is a true journalistic gift. Kudos.
Journos, please, contact us about what OSF supposedly said before putting said comments into your writings. We’re usually available, and typically somewhat pleasant to deal with. We also keep tabs on current events, as well as whatever you write that makes it onto Google News. Just sayin’. 🙂
Posted by Lyger