Most people would agree that security is important; however, many would have a hard time saying that a data breach could be a life or death situation. Sadly, in the past few weeks there have been two cases that may qualify for that characterization in the news.
The first case is the data breach at King Edward VII Hospital on December 4, 2012. Two Australian radio show hosts prank called the hospital in a joking attempt to get information on the condition of the Duchess of Cambridge. To their surprise the nurse, who answered the phone, fell for the hoax and provided them with information on the Duchess’s condition and care. Last Friday, Jacintha Saldanha, the 46 year old nurse who provided the information, committed suicide just two days after news of the breach was released.
The second case involves a data breach that occurred September 28, 2012 at the University of Georgia. A former student gained unauthorized access to a server containing 8,500 former and current employees’ names, Social Security numbers, and other sensitive information. Still in the midst of investigation, police announced on Tuesday that Charles Stapler Stell, the 26 year old behind the data breach, passed away with no indication of foul play and most likely the result of suicide.
In these two cases, the data breaches and their consequences appeared to have pushed these individuals into a life or death decision. As the importance of privacy and security breaches increases, we have now seen there are potential ramifications to the people involved, more than just notification and credit monitoring.
As breaches unfortunately become more commonplace, organizations impacted should ensure that they not only have a response plan for dealing with the incident, but also how to constructively handle any employees at fault. While discipline from HR may be on the agenda, organizations need to ensure the wellbeing of their employees as they process their actions.
Written by eabsetz
From time to time, the Open Security Foundation is contacted about security vulnerabilities and data breaches that have yet to be made public. We always strive to handle each report in the most appropriate way possible and wanted to share with you an example from last year. In March of 2011, we had a breach anonymously submitted to DataLossDB without any further way to contact the submitter, but enough information for us to work on verifying and relaying the issue to the affected company.
From the initial look of things, it appeared that job applicants’ names, addresses, phone numbers, email addresses, and resumes were accessible and even editable on the Computer Sciences Corp (CSC) website without requiring a login. You could browse to their resume website and increment the ResumeID=x field in the URL making it trivial to enumerate and access approximately 300 applicants personal information.
We contacted CSC as soon as the incident was submitted to see if they would speak to us or at least provide a response. At first it appeared that they ignored our emails and we were getting a bit concerned as several days went by without a response. However, once we escalated to a phone call, we were then able to discuss the issue with the proper contacts and the vulnerability was fixed within 48 hours. We also spoke with their lawyer and they stated that they would notify those affected and get back to us with a statement.
Here is the statement from CSC:
————————– Original Message ————————–
Last month, CSC was contacted by Open Security Foundation (“OSF”) who had received an anonymous tip that an Internet-accessible Web site CSC had set up for a recruiting effort had security issues. Upon internal investigation, it was determined that the site created in 2006 was unintentionally architected in such a way as to allow for url manipulation once a person created a profile for themselves, giving them the ability to see other person’s resume information. CSC has no evidence that anyone other than the original anonymous tipster and those associated with OSF actually had access to resume information. This site was not properly de-provisioned and remained accessible until 2011 (although the last resume received was in September 2010). The contents, however, were not indexed or searchable by Google. There were approximately 300 profiles created with varying amounts of personal information provided. Although CSC did not ask for or require birth dates or Social Security Numbers, eight people provided either one or both. One person provided the last four digits of a SSN. CSC will provide formal notification as required by state law. In addition, where there is no state requirement, CSC will nonetheless send letters to inform everyone about the vulnerability.
Due to our delay, we have just now pushed this incident live and wanted to thank the anonymous submitter for providing us the information so we could responsibly report it and to CSC for responding to the breach appropriately.
To be clear, after we spoke with CSC on the phone and were able to get connected to the right people they responded promptly, did a thorough investigation, and then to our knowledge notified everyone. Our delay in posting this update and pushing the incident live in no way is an indication one way or the other about CSC. In fact, it just highlights the continued challenges for the Open Security Foundation to keep up with the massive amount of breaches that continue to occur every day.
In addition, we thought we would post this particular example to share some of the work that happens behind the scenes at OSF, that many people would never know exists. Coordinating with organization such as this can take a great deal of time and patience on both sides. Whenever possible and practical we do go out of our way to alert entities to breaches, but at other times we unfortunately just have to post the breach. We would love to contact all entities to confirm they are aware of the incident and offer assistance but this is not possible. For example, while we may from time to time we don’t typically contact organizations for breaches when the data is posted publicly such as when information is dumped to Pastebin or other paste sites. Unfortunately, we do not have sufficient staff to always do that and some sites do not make it easy to contact them.
We would love to be able to do more with the project, but unfortunately just have not been able to get the support or volunteers required. Moving forward, we will be making changes with the project to help ensure our future. This will begin with a new partnership with Risk Based Security, which will be able to bring more resources to better support the project and continue our research.
We thought keeping track of entities involved in the Epsilon breach was tough, but the recent spate of attacks on Sony networks has us working overtime trying to update the database. Thankfully, Jericho provided yeoman service and compiled a hyperlinked chronology of recent developments.
The Sony breaches have generated a lot of discussion. Some of it has centered on Sony’s shocking failure to encrypt passwords and it being all-too-vulnerable to SQLi compromises (if those posting the data publicly are accurate as to how they compromised certain databases). Sony undoubtedly has a lot of explaining to do if it hopes to have future assertions of industry-standard security taken seriously.
To date, the two largest incidents affected over 100 million records. But were the PSN and Sony Online Entertainment (SOE) attacks two separate incidents or were they really one breach? Should DataLossDB.org have recorded one breach with over 100 million affected, or two incidents involving 77 million and 24.6 million, respectively? Or should we just treat the last 45 days’ incidents as one #EPIC #FAIL and one big incident? In light of our mission to track unique breaches, the question is not trivial.
When news of the second incident broke, the first thought was to update the PSN entry and add another 24.6 million to that counter. But as more details emerged, it seemed clear that we should treat it as a separate incident. The attack had occurred on different days than the PSN attack, the data compromised were on different networks, it seems quite likely the different networks had different security measures involved (Sony later testified that databases with credit card data were treated with higher security), we did not know if the same individuals were involved in both attacks, and the company itself was reporting it as a second incident previously unknown to them and not as an update to the other breach. Our impression that these were two unique incidents was subsequently supported by the reports made to the New Hampshire Attorney General’s Office for each incident (here and here).
Despite what we thought was an accurate way to track these breaches, one commenter to DataLossDB.org questioned our decision to treat the reports as two unique incidents. A researcher with Javelin Strategy commented that treating this as two incidents instead of one benefited Sony: they would not appear ranked 2nd in our list of all-time largest breaches on our home page. Since these incidents had the same parent corporation, he suggested, they should be treated as one aggregated incident.
While those points may appear reasonable to some, we find them unpersuasive. First, we do not make decisions based on whether an entity benefits or suffers from a particular decision. We make decisions based on whether the available information supports aggregating the data for a particular incident or not. In this case, although it is the same parent corporation, the available information does not support aggregation. In other cases, such as a Wellpoint breach that was initially entered as distinct incidents, when my research revealed that there was only one incident and that what appeared to be a second incident was really due to Wellpoint’s vendor not fully securing the web sites after the first report, I recommended that those incidents be combined, and they will be. But other than a common target – Sony – where is there any evidence that this was just one incident? There is none.
We recognize that not everyone will agree with our decision, and that’s fine. Should new information become available that suggests that a one-incident approach is more appropriate for these incidents, we will edit our entries.
As always, we welcome constructive thoughts about how to make the database more useful to stakeholders, but we do not expect all of our decisions to please everyone.
By now, everyone has probably read about a company named Epsilon. In fact, most people likely have second hand involvement, receiving one or more emails from companies you do business with warning you to be very careful after a recent incident. Most of these companies have used a similar form letter explaining the concerns and that you should be “cautious of phishing e-mails, where the sender tries to trick the recipient into disclosing confidential or personal information.” These notifications stem from Epsilon, a managed e-mail broadcasting company, getting compromised and having all of their customer e-mail addresses copied.
We have received a few emails from people asking us how we could have missed the Epsilon breach and why it isn’t on our site. Well, it actually is on the site as we do follow incidents such as this, however, it is listed as a Fringe incident. Why “Fringe”? From what we can tell so far, the breach (while unacceptable) is contained to Names and Email Addresses. We do recognize that this information may increase the risk to customers as targeted spearphishing attempts may be more successful, however, there is no loss of PII. We have debated this topic for years and instead of not including them in DataLossDB, they are now just labeled Fringe. There will be more debate on the severity of this incident for sure. Some think it is critical and others merely say that their email address was never meant to be private anyways. There are good arguments supporting both sides of the debate.
We will be continuing to add all of the affected organizations as we learn about them, and you can see the incident here: http://datalossdb.org/incidents/3540
When Epsilon posted the notice on their site they mentioned: “On March 30th, an incident was detected where a subset of Epsilon clients’ customer data were exposed by an unauthorized entry into Epsilon’s email system.”
As on April 4th, they have now have updated the definition of “subset” to mean “The affected clients are approximately 2 percent of total clients and are a subset of clients for which Epsilon provides email services.”
As of today, we are aware of a little over 40 companies affected and more notices are pouring in from users. As to how many users are impacted that is anyone’s guess. Our guess is A LOT.
If you want to read some of the notices we have received, over a dozen are on our mailing lists archives: http://lists.osvdb.org/pipermail/dataloss/2011-April/thread.html
For those that want to play along, we have decided to make some Epsilon Bingo Cards. If you are able to fill up a whole card and prove it with the notices we might have to give you a prize… that is the least we could do, right?
As always, please keep sending us any notices that we are missing so that we may better gauge the scope of this incident and update the cards.
OSF has worked with Dissent over the years and she is already known to us a DataLoss Archaeologist, as she took third place in our “Oldest Incident” contest. She found the 1984 TRW incident, where computer hackers gained access to a system holding credit histories of some 90 million people which happens to be the 3rd largest breaches of all time in DataLossDB. Her more active involvement with the project on a day-to-day basis will help us remain the most complete archive of dataloss incidents world-wide and will enhance our ability to keep current on more breaches in a timely manner. Dissent will continue to maintain her own web sites as a resource on breach news and issues.
For those who do not know Dissent, she’s a practicing health care professional with a special concern for health care sector breaches, and we expect to see increased coverage of medical sector breaches in the database in months to come. As Dissent notes, “With recent changes to federal laws making more information available to us about health care sector breaches, we are now beginning to get some sense of how common these breaches are and the common breach types. Including these incidents in the database will enable analyses that would not have been possible or meaningful just a few years ago.”
Open Security Foundation’s CEO, Jake Kouns says, “Dissent has been a supporter of DataLossDB from the very beginning and is an extremely dedicated and thorough researcher.” “We are extremely fortunate to have her as part of the DataLossDB team and look forward to working more closely with her.”
Welcome Dissent, our newest curator and resident research queen!
As security vulnerabilities and data loss incidents become a regular occurrence, the Open Security Foundation has grown from supporting a single project in 2004 to a leading provider of filtering through security information and providing notifications and aggregation for data for data loss and cloud security incidents.
The Open Security Foundation has evolved into one of the most utilized resources in providing security information, and as a 501c3 non-profit organization relies heavily on public contributions, volunteer effort and corporate sponsorships.
The growing demand for information to provide proper risk management has led to additional projects and now the introduction of an advisory board consisting of industry professionals to lend their expertise in areas to keep OSF moving in a positive direction and to be the first line of access to all that require their service.
Open Security Foundation CEO and founder Jake Kouns stated, “This is a very important step in shaping the future of the Open Security Foundation.” “OSF has reached a point in growth that requires a strategic move to provide longevity and sustainability. It has always been a goal of this organization to provide our work to the broadest audience and the introduction of the advisory board will contribute to that objective. I am extremely proud to be part of such an amazing organization that has built a reputation of excellence and serves a very important function,” adds Kouns. “We put out a call for qualified individuals that could provide guidance and insight to keep OSF a leader in the security information arena. The results of our search far exceeded our highest expectations; it’s not only provides us with confidence in our direction, but the impact OSF has had on the industry.”
The new advisory board members comprises of an array of specific industries that understand the importance of OSF resources. Each member was chosen for a specific contribution to ultimately achieve the objective and mission of this foundation and capable of providing broad based perspective on information security, business management and fundraising.
Tom Srail, Senior VP Willis Group provides 19 years of experience in the insurance industry with an expertise in risk consulting, professional liabilities, network security risks, intellectual property and technology professional risks.
Shawn Andreas, VP Marketing Guard Dog Inc.(GRDO.PK) will contribute his 20 years of experience in marketing and brand awareness to remake OSF to be more consumer and market friendly focusing on fundraising and sponsorships opportunities. His expertise in marketing spans over diverse markets and includes opportunities working with some of the country’s top companies including GM, Apple, Viacom and more.
Jim Hietala VP, Security for a leading IT standards organization, manages all security and risk management programs. Mr. Hietala is a frequent speaker at industry conferences. In addition he has published numerous articles on information security, risk management and compliance topics.
Daniel E. Geer, Jr. Sc.D. Chief Information security officer In-Q-Tel Washington. Mr. Geer has a list of accomplishments including participation in government advisory roles for the Federal Trade Commission, the Departments of Justice and Treasury, the National Academy of Sciences, the National Science Foundation, the US Secret Service, the Department of Homeland Security, and the Commonwealth of Massachusetts.
Andrew Lewman, Executive Director The Tor Project, Inc. Andrew Lewman is the Executive Director of The Tor Project, a non-profit organization. Mr. Lewman worked on projects with the National Science Foundation, Internews Network, Freedom House, Google, Broadcasting Board of Governors, National Network to End Domestic Violence, and the US State Department.
In addition to the advisory board, OSF also announces new leadership positions with the organization. We are pleased to announce that Becky Chickering and Corey Quinn are now curators for the DataLossDB project. We want to thank everyone that contacted OSF to volunteer their time and skills for the advisory board and flexibility as we went through this process. During our conversations with potential members we spoke with several passionate individuals that have a great deal to offer OSF. We plan to continue to expand our leadership team and are always looking for volunteers to help the organization.
The Open Security Foundation, providing independent, accurate, detailed, current, and unbiased security information to professionals around the world, announced today that it has launched Cloutage (cloutage.org) that will bring enhanced visibility and transparency to Cloud security. The name Cloutage comes from a play on two words, Cloud and Outage, that combine to describe what the new website offers: a destination for organizations to learn about cloud security issues as well as a complete list of any problems around the globe among cloud service providers.
The new website is aimed at empowering organizations by providing cloud security knowledge and resources so that they may properly assess information security risks related to the cloud. Cloutage documents known and reported incidents with cloud services while also providing a one-stop shop for cloud security news and resources.
“When speaking with individuals about the cloud, to this point it has been a very emotional conversation. People either love or hate the cloud,” says Jake Kouns, Chairman, Open Security Foundation. “Our goal with Cloutage is to bring grounded data and facts to the conversation so we can have more meaningful discussions about the risks and how to improve cloud security controls.”
Cloutage captures data about incidents affecting cloud services in several forms including vulnerabilities that affect the confidentiality and integrity of customer data, automatic update failures, data loss, hacks and outages that impact service availability. Data is acquired from verifiable media resources and is also open for community participation based on anonymous user submissions. Cloud solution providers are listed on the website and the community can provide comments and ratings based on their experiences. Cloutage also features an extensive news service, mailing lists and links to organizations focused on the secure advancement of cloud computing.
“The nebulous world of cloud computing and the security concerns associated with it confuses many people, even IT and security professionals,” says Patrick McDonald, a volunteer on the Cloutage project. “We want a clearinghouse of information that provides a clear picture of the cloud security issues.”
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: