<![CDATA[Google Online Security Blog]]> http://securityratty.com/feed/6b9198c6edc1ad60e4a34c25e1ceaba8 Mon, 05 May 2008 07:38:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[New spam and virus trends from Enterprise]]> http://securityratty.com/article/ecd17c809af327b45b4ff7c2e1191722 http://securityratty.com/article/ecd17c809af327b45b4ff7c2e1191722 Written by Amanda Kleha, Google Apps Security & Compliance team


The Google Apps Security & Compliance team, which provides email and web security for more than 40,000 companies, regularly tracks trends in spam, viruses, and other threats. Check out some of our latest findings over on the Enterprise blog. Also, on Friday, August 15, at 10:00 am PT, we'll be hosting a webinar on keeping your business safe from web and email threats -- tune in if you'd like to learn more.
]]> Tue, 12 Aug 2008 10:01:00 +0000 google apps security compliance team email email threats web security threats web regularly tracks trends enterprise blog New spam and virus trends from Enterprise <![CDATA[Safe Browsing Diagnostic To The Rescue]]> http://securityratty.com/article/2838c04613111b3f4292050571ed4d23 http://securityratty.com/article/2838c04613111b3f4292050571ed4d23 Posted by Niels Provos

We've been protecting Google users from malicious web pages since 2006 by showing warning labels in Google's search results and by publishing the data via the Safe Browsing API to client programs such as Firefox and Google Desktop Search. To create our data, we've built a large-scale infrastructure to automatically determine if web pages pose a risk to users. This system has proven to be highly accurate, but we've noted that it can sometimes be difficult for webmasters and users to verify our results, as attackers often use sophisticated obfuscation techniques or inject malicious payloads only under certain conditions. With that in mind, we've developed a Safe Browsing diagnostic page that will provide detailed information about our automatic investigations and findings.

The Safe Browsing diagnostic page of a site is structured into four different categories:

  1. What is the current listing status for [the site in question]?

    We display the current listing status of a site and also information on how often a site or parts of it were listed in the past.

  2. What happened when Google visited this site?

    This section includes information on when we analyzed the page, when it was last malicious, what kind of malware we encountered and so fourth.   To help web masters clean up their site, we also provide information about the sites that were serving malicious software to users and which sites might have served as intermediaries.

  3. Has this site acted as an intermediary resulting in further distribution of malware?

    Here we provide information if this site has facilitated the distribution of malicious software in the past. This could be an advertising network or statistics site that accidentally participated in the distribution of malicious software.

  4. Has this site hosted malware?

    Here we provide information if the the site has hosted malicious software in the past. We also provide information on the victim sites that initiated the distribution of malicious software.


All information we show is historical over the last ninety days but does not go further into the past.   Initially, we are making the Safe Browsing diagnostic page available in two ways.  We are adding a link on the interstitial page a user sees after clicking on a search result with a warning label, and also via an "additional information" link in Firefox 3's warning page. Of course, for anyone who wants to know more about how our detection system works, we also provide a detailed tech report [pdf] including an overview of the detection system and in-depth data analysis.
]]> Thu, 15 May 2008 09:49:00 +0000 provide information information malicious malicious web pages malicious software site statistics site site acted provide Safe Browsing Diagnostic To The Rescue <![CDATA[Contributing To Open Source Software Security]]> http://securityratty.com/article/04630345d95c997a99d8d781a3b761d6 http://securityratty.com/article/04630345d95c997a99d8d781a3b761d6 Written by Will Drewry

From operating systems to web browsers, open source software plays a critical role in the operation of the Internet. The security of open source software is therefore quite important, as it often interacts with personal information -- ranging from credit card numbers to medical records -- that needs to be kept safe. There has been a long-lived discussion on whether open source software is inherently more secure than closed source software. While popular opinion has begun to tilt in favor of openness, there are still arguments for both sides. Instead of diving into those treacherous waters (or giving weight to the idea of "inherent security"), I'd like to focus on the fruits of this extensive discussion. In particular, David A. Wheeler laid out a "bottom line" in his Secure Programming for Linux and Unix HOWTO which applies to both open and closed source software. It predicates real security in software on three actions:

  1. people need to actually review the code

  2. developers/reviewers need to know how to write secure code

  3. once found, security problems need to be fixed quickly, and their fixes distributed quickly


While distilling anything down to three steps makes it seem easy, this isn't necessarily the case. Given how important open source software is to Google, we've attempted to contribute to this bottom line. As Chris said before, our engineers are encouraged to contribute both software and time to open source efforts. We regularly submit the results of our automated and manual security analysis of open source software back to the community, including related software engineering time. In addition, our engineering teams frequently release software under open source licenses. This software was written either with security in mind, such as with security testing
tools, or by engineers well-versed in the security challenges of their project.

These efforts leave one area completely unaddressed -- getting security problems fixed quickly, and then getting those fixes distributed quickly. It has been unclear how to best resolve this issue. There is no centralized security authority for open source projects, and operating system distribution publishers are the best bet for getting updates to the highest number of users. Even if users can get updates in this manner, how should a security researcher contact a particular project's author? If there's a potential, security-related issue, who can help evaluate the risk for a project? What resources are there for projects that have been compromised, but have no operational security background?

I'm proud to announce that Google has sponsored participation in oCERT, the open source computer emergency response team. oCERT is a volunteer workforce of security professionals from the open source community with the goal of providing security vulnerability mediation and incident response services to open source projects. It will strive to contact software authors with all security reports and aid in debugging and patching, especially in cases where the author, or the reporter, doesn't have a background in security. Reliable contacts for projects, publishers, and vendors will be maintained where possible and used for notification when issues arise and fixes are available for mediated issues. Additionally, oCERT will aid projects of any size with responses to security incidents, such as server compromises.

It is my hope that this initiative will not only aid in remediating security issues in a timely fashion, but also provide a means for additional security contributions to the open source community.
]]> Mon, 05 May 2008 07:38:00 +0000 security source software software additional security contributions background operational security background security professionals security vulnerability mediation manual security analysis Contributing To Open Source Software Security