Nothing is certain but death, taxes and identity theft.

As we are well into tax season, there has been a trend of articles in the news involving identity theft and tax fraud. Individuals are stealing information from various sources, which are not only businesses, but also straight out of mailboxes in order to commit identity theft and file false tax returns. Some of these criminals have been reported to net as much as $11 million with their schemes before being caught. 641,690 incidents had been identified by the IRS as of September 30, 2012.

Each of these incidents are a concern. However, all are not reported in DatalossDB as we require data loss incidents to have a steward organization. Therefore, we submit only to our database the schemes where personal data is stolen from an organization or business, but discard those where the data is stolen out of mailboxes as they don’t fit our requirements.

Here are some snippets of the latest cases we have seen in the news; these cases include both ones DatalossDB would and would not catalog. There seems to be a trend in state employees and tax preparers stealing information to file false tax returns themselves or to sell the personal information to others.

In one case in Alabama, a state employee obtained identification information from a state database from October 2009 until April 2012. That is two and a half years in which she went undetected while working with co-conspirators to file over 1,000 false tax returns and receiving fraudulent returns totaling $1.7 million.

In Los Angeles County, the Department of Public Social Services had an employee, who as a receptionist had access to the systems to input data and assistance requests. She took screenshots of 132 applicants’ PII (Personally Identifiable Information), and with the help of her husband and friends filed 65 tax returns in 2011 netting a total of $357,704.90 in fraudulent claims.

In Silver Spring, MD, two brothers running a tax service together stole identities from Puerto Rican residents to submit fraudulent claims through their business. They filed 13 false returns totalling $43,264.

Another tax preparer used information of previous clients and deceased persons in order to defraud the IRS and taxpayers for over $200,000 from 2003 to 2008.

The largest case we’ve seen, which is currently awaiting sentencing, took place in Fort Lauderdale and involved the filing of around 2,000 false tax returns from October 2010 until June 2012. This particular identity theft tax fraud scheme pulled in over $11 million.

To many, this might seem like a great way to make money. Here are some of the punishments that have or will befall these criminals. If convicted, the Alabama state employee is facing 20 years for each wire fraud count, 10 years for each computer fraud count, 10 years for conspiracy to file false claims, 2 years for aggravated identity thefts, fines, and mandatory restitution. The tax preparer, who used client and deceased persons information, was sentenced to 60 months in prison and paying full restitution amounting in excess of $200,000. As for the case where the scheme pulled in around $11 million, one of the women involved is looking at possibly being sentenced to 351 years. That is around 6 lifetimes of prison!

The IRS is taking action in response to the increase in tax related identity theft over the last few years. They have activated new identity theft filters, and are working with over 130 financial institutions to help identify identity theft schemes. The IRS has also trained over 35,000 people, who have direct contact with taxpayers, in ways to help identify red flags associated with identity theft, and they have doubled the employees in their tax related identity theft department.

Multiple resources including the IRS are recommending a few things to help keep your identity safer. Make sure that you do not carry your Social Security card around in your wallet or purse; if you do, take it out and place it somewhere secure. In fact, it is a good idea to take any documents containing personal information and secure them in your home. Many businesses ask for your Social Security number, even if it is not mandatory information. It is best to not automatically provide it every time you are asked. Never give out your personal information over the phone or email; the IRS does not contact taxpayers either way to acquire information. Monitoring your credit report on a regular basis can help to identify identity theft, hopefully before the loss becomes severe.

Written by eabsetz

Knock, knock. Who’s there? No one.

As we mentioned in our last post, trying to contact and confirm organizations that have reportedly been breached can be time-consuming and frustrating. When that organization is a hospital and we cannot reach anyone or get a response, it’s especially concerning.

Yesterday, I tried to contact [Redacted] Hospital. I went to their site for contact info, but they had no phone directory or email directory by department or office. So I called their main number and asked for IT. I was sent to voicemail. I hung up, called back, and asked the operator to stay on the line until I got through to a person in IT or the Privacy Compliance Officer. Eventually, I heard a male voice, who told me that he was the “service desk.” The “service desk” was not IT. I subsequently learned that they are an outsourced IT partner.

I explained that the hospital had apparently suffered a hack via SQL injection and I could email him a link to the data so that IT could investigate and take action to secure the server better. I gave him my name, email address, and phone number, and told him that I was with the Open Security Foundation.

He told me didn’t have an email address for me to email him the link, but that he would open a ticket. He had no email address to give me? Seriously? On the one hand, not accepting an emailed link from a stranger makes good security sense, but on the other hand, how could I send them data and details without an email address? I usually paste some dumped data into the body of the email with the link to the full paste. So now, not only could I not directly reach the responsible parties, I could not even send them any data to pursue.

The service desk employee opened a ticket and sent me a copy of it. That was almost 24 hours ago. The two individuals he directed the ticket to were the hospital’s System Administrator and Technical Analyst, neither of whom have contacted me by email or phone, even though my contact details were in the support ticket.

In this case, the data were dumped on the Internet at the beginning of December 2012, so maybe they know already, but since the data are still live and in any event, they have no idea what data I called about, maybe they don’t know. The data do not appear to be patient data, but they are personally identifiable information. And if those data were vulnerable, what other data might still be vulnerable?

Another staff member from OSF also tried to reach them last night – through the hospital’s on-site contact form. That form doesn’t have a pull-down menu to direct the message to particular subjects or departments.

It shouldn’t be so difficult to contact the responsible party when there’s been a breach. So here are some “best practices” recommendations for HIPAA-covered entities to add to their checklists:

1. Provide a dedicated phone number and email address to report privacy or security breaches and prominently post those contact details on the home page of your web site.
2. Ensure that the phone number and email address are monitored 24/7/365.
3. Establish a written policy that all such contacts or messages are to be acknowledged within 1 hour.
4. Follow up and let the individual who reported the problem know what steps you have taken.
5. If you use a contact form on your web site, have a pull-down menu for subjects, and have one of them be “Privacy or Security Concern.”

Every hospital tells patients that they take the privacy and security of their information seriously. I wouldn’t believe them if they don’t respond to security alerts and make people jump through hoops just to try to inform them that they may have had a breach involving personal information. And I certainly wouldn’t believe any hospital that doesn’t even return a phone call when you have left them a message that they may have a security problem with their public-facing server.

Responsible hospitals should facilitate reporting privacy or data security concerns. So what has your organization done to facilitate reporting of breaches?


Fool us once, shame on you. Fool us twice, we implement policies!

It had all the makings of a sexy data breach story. An individual with the Twitter nick of @TibitXimer claimed to have exploited a vulnerability on Verizon’s server and dumped about 300,000 records out of an estimated 3,000,000 customer records allegedly acquired.

ZDNet trumpeted the headline, “Exclusive: Hacker nabs 3m Verizon customer records.” They reported:

“A hacker has posted around 300,000 database entries of Verizon customers to the Web, after exploiting a vulnerability in the cellular giant’s network.

The hacker, going by the name @TibitXimer on Twitter, told ZDNet earlier this evening that the hack was carried out earlier this year on July 12, which allowed him to gain root access to the server holding the customer data. Tibit gained access to a server with little difficulty after working with another hacker to identify the security flaw.”

The problem is that although none of it was true, @TibitXimer’s claims and ZDNet’s repetition of the claims were repeated all over the Internet.

One day later, @TibitXimer was gone from Twitter and a more accurate version of the story started to emerge. In statements to other media outlets such as, The Next Web, and Forbes, Verizon spokesperson Alberto Canal explained that Verizon’s systems had not been breached at all, there was no vulnerability exploited, no root access gained, and that the data dumped were old data from an incident a few months ago.

To add insult to the reputation harm that Verizon could have suffered, the incident wasn’t even Verizon’s incident. It turned out that a third party marketing firm that Canal did not name had accidentally leaked a sales lead list and the list had simply been copied and posted at the beginning of August. Most of the names on the list were not even Verizon customers, according to Canal. The same data were re-posted this week and claimed as a new “hack.”

Not such a sexy story anymore, right? And ZDNet is certainly not the only media source to believe a hacker’s claims that were subsequently determined to be totally untrue. We’ve been fooled, too, at times, as has Lee Johnstone, who recently had to correct a report on Cyber War News that a hacker named “Hannibal” had leaked 1,000,000 Facebook account details in retaliation for #OpIsrael.

Over the past year, the problem of false claims has reached almost epidemic proportions, which is why, over the past few months, started implementing policies requiring us to obtain – or at least make a good faith effort to obtain when possible – a statement from an allegedly breached entity either confirming, denying, or clarifying and correcting a hacker’s claims of a breach – *before* we decide whether to add a report to the database.

Sometimes, as in this case, it is relatively easy to reach a media contact and get a response. In other cases, particularly with small entities involved in claimed hacks overseas, it is not so easy, and we may send several e-mails that go unanswered before we try to decide whether to include a claimed breach or not. If you login and read individual entries, you may even see a Curator’s Note in the Comments section indicating that we tried and failed to reach anyone by e-mail to confirm the report.

Deciding whether to include a report when we cannot reach anyone is headache-inducing, to say the least, as we realize that with this less than perfect system, entities might suffer reputation harm through no fault of their own. We have therefore also implemented the ability to fully delete entries from the database should we later learn that a claim was totally false.

Another policy we recently implemented involves putting (DISPUTED) in the summary line for an incident if there is a real dispute as to whether a breach occurred or not. There may be times when an entity insists they have not been breached but we find the evidence in a data dump to be compelling and decide to include the report. This was the case, for example, in the reported hack of, where they denied it to and others, but analysis of the data dump and information still available on their site led us to the decision to include the report. At other times, a reported breach may be part of litigation and where the defendant denies the claims, we may decide to include the report but note it as DISPUTED.

Trying to confirm the numerous claimed hacks that appear on Pastebin or other sites on a daily basis is a time-consuming process that slows us down in providing timely reports and has put even more pressure on our resources that are already constrained. However, we believe that it needs to be done to ensure data quality. And so, as 2012 draws to a close, we have already added over 1,400 incidents (and that number does not include the Fringe incidents) for the year, but there are hundreds more still to process. Whatever number you see on the Stats page for December 31st will likely be significantly under our real total for the year until we can catch up.

On that note, I wish you all a Happy and Healthy 2013. And let’s hope that next year, things slow down for us!


Is A Data Breach A Life Or Death Situation?

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

Behind the scenes of doing the right thing

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.

Sony had HOW many breaches?

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 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 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.

/ Dissent

Epsilon Bingo

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:

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:

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.

The DataLossDB project welcomes Dissent!

The Open Security Foundation is pleased to announce that Dissent, the publisher and maintainer of and has now joined DataLossDB as a curator for the project.

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!

Open Security Foundation Announces New Advisory Board

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.

Open Security Foundation Launches New Cloud Security Project

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 ( 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.”