reporting

reporting

Observations from StopBadware's first foray into reporting

Posted on September 2, 2011 - 10:22 by ccondon

As we mentioned last week, we have a full and public draft of a new best practices document for reporting badware URLs. You may also be aware that StopBadware receives a feed of badware URLs reported by members of our BadwareBusters community, via this form. The community feed is represented in our Clearinghouse, but it’s discrete from any data we receive from our data providers (Google, GFI-Sunbelt, and NSFocus).

For the past six weeks, our testing team has been reporting the URLs from our community feed in accordance with the current draft of our Best Practices for Badware Reporting. This inaugural effort at reporting is only a pilot project, and we have not yet decided whether to continue or expand the work. That said, the reporting we’ve done these past couple of months has given us a much better feel for the reporting landscape and the needs of both hosting providers and reporters endeavoring to take down badware and protect users.

Naturally, our immediate goal when we started reporting URLs from our community feed was to put our new best practices to a practical test. A side effect of this test, however, was that we have begun to witness firsthand the variation in hosting provider responses to reports of badware on their networks. We’ve made some intriguing discoveries in the course of our reporting efforts; in the spirit of our commitment to transparency and improving the Internet ecosystem’s collective resiliency to badware, we’d like to share some of our results.

Our team’s reporting steps were as follows:

  1. They manually investigated the reported badware URL to determine whether badware was, in fact, present.
  2. If badware was observed, our testers used their considerable experience to determine (as much as possible) whether the URL was inherently malicious or a compromised, legitimate site.
  3. They contacted the appropriate entities as laid out by our Best Practices for Badware Reporting. In most—though not all—cases, our team simultaneously contacted the site owner and the hosting provider; please see the current draft of StopBadware’s Best Practices for Badware Reporting for an explanation of appropriate points of contact for various reporting scenarios.

Notable observations:

  • A full 67% of the URLs we reported were cleaned up, many within a short time.
  • Dropbox, who qualifies as a web hosting provider by the definitions set out in our Best Practices for Web Hosting Providers, was particularly responsive to badware reports. Every report sent their way was acknowledged and addressed quickly, many reports were met with personal responses, and some badware URLs on their network were taken down in as little as 45 minutes.
  • Dreamhost, Bluehost, Brazil’s Universo Online S.A., German host Hetzner Online, and Chicago-based WiredTree were also among the most responsive: frequently our team received personal responses from these hosting providers, and badware URLs we reported to them were, without exception, cleaned up or taken down.
  • Though two thirds of the URLs we reported were cleaned up, only 26% of the reports were acknowledged. (Note: Our Best Practices for Web Hosting Providers specify that providers should acknowledge receipt of badware reports within one business day and should follow up with information about action taken.)
  • Of the reports that did receive acknowledgments, 81% were cleaned up. When the acknowledgment was a personal response, that number rose to 95%.

Several conclusions seem clear to us from our experience thus far. Open communication channels are key to both reporting and responding to reports.  The framework provided by our reporting best practices held up, though implementation inevitably varied based on proactive replies from individual hosting providers; unsurprisingly, open communication was instrumental in those minute changes, too—for instance, when a hosting provider preferred the reporter to submit abuse complaints via a web form. Finally, size is not an impediment to responsible communication and follow-up, as evidenced by the varying sizes of the providers listed above.

Of course, the list of hosting providers we’re recognizing for exemplary responses is preliminary and not meant to be exhaustive. Undoubtedly, there are a great many responsive and proactive hosting providers to whom we haven’t yet reported badware URLs. (If you’re a hosting provider whose policies and procedures are in compliance with our Best Practices for Web Hosting Providers, you can sign up for our We Stop Badware™ Web Host program to show potential customers your commitment to fighting badware.)
 

We’re actively soliciting comments on our Best Practices for Badware Reporting until September 16, 2011. We welcome feedback from hosting providers, reporters, and other members of the security community, as well as from concerned users and members of our community. Feedback can be posted to our blog or sent to contact<at>stopbadware.org.

StopBadware to develop best practices for malware reporting

Posted on April 29, 2011 - 14:26 by ccondon

Last month, we released a set of best practices for hosting providers responding to malware reports. The best practices are intended  to address inconsistency within the industry about how to responsibly and effectively respond to malware reports; they lay out a high-level framework that web hosting providers of all sizes can follow. Today, we at StopBadware are pleased to announce that we have already begun to take the logical next step in helping to strengthen the Web ecosystem: developing a set of best practices for malware reporters. 

This second set of best practices will provide a high-level framework for reporting URLs that host, link to, or deliver malware. Developing best practices for malware reporters is a natural continuation of our work in the web hosting arena, and we expect this new best practices document to complement and enhance our best practices for web hosting providers. It’s our hope and expectation that this new effort will help security researchers and corporate IT departments communicate effectively and efficiently with hosting providers, site owners, and other relevant parties. We also expect the process of developing best practices for malware reporters to serve as a strong foundation for a new centralized reporting system we at StopBadware are planning to build.

 

Our best practices for web hosting providers were developed with the advice of an advisory working group that included representatives from top hosting providers, security companies, and policy organizations; this group ensured that the Practices were sensible and complete, but perhaps of even greater value was the discussion and collaboration that arose among the group’s diverse members as we worked to formulate the final document. Given the level of engagement and the quality of the discussion produced by our Web Hosting Working Group, it was an easy decision to assemble a second equally diverse working group to assist us in developing our best practices for malware reporters. We’ve already opened discussion with our Malware Reporting Working Group, and we look forward to listening to their insights over the next few months.

 

We’re extremely excited to be focusing on this project: it strengthens another crucial in the Web’s chain of trust, it encourages the high-level discussion we’re happy to be known for, and it’s a perfect example of the kind of collective action StopBadware’s mission is all about. We’ll likely be releasing public drafts of our best practices for malware reporters in the near future, so stay tuned or subscribe to get the latest updates and requests for comment.