<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Salesforce.com and the debate over SaaS security, email confidentiality</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/security-bytes/salesforcecom-and-the-debate-over-saas-security-email-confidentiality/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/security-bytes/salesforcecom-and-the-debate-over-saas-security-email-confidentiality/</link>
	<description>A SearchSecurity.com blog</description>
	<pubDate>Sat, 28 Nov 2009 20:01:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: low_profile</title>
		<link>http://itknowledgeexchange.techtarget.com/security-bytes/salesforcecom-and-the-debate-over-saas-security-email-confidentiality/#comment-426</link>
		<dc:creator>low_profile</dc:creator>
		<pubDate>Tue, 13 Nov 2007 19:19:05 +0000</pubDate>
		<guid isPermaLink="false">http://security.blogs.techtarget.com/2007/11/02/salesforcecom-and-the-debate-over-saas-security-email-confidentiality/#comment-426</guid>
		<description>It's not "whether or not a SaaS vendor can secure those Web applications better than its clients could on their own."

It's "will the SaaS vendor secure those apps appropriately for all clients."

The decision of how much security is good enough will be made by the SaaS vendor, based on their financial model and risk tolerance, and most of their clients will never realize that their own risk model isn't considered except very indirectly.

Likewise, notification of email address exposure shouldn't be left to the discretion of the compromised (and thus embarassed) vendor.  Clients of SaaS vendors should include contractual requirements for notification of any breach or compromise, regardless of extent.  It's part of the information required to properly evaluate SaaS vendor quality of service.</description>
		<content:encoded><![CDATA[<p>It&#8217;s not &#8220;whether or not a SaaS vendor can secure those Web applications better than its clients could on their own.&#8221;</p>
<p>It&#8217;s &#8220;will the SaaS vendor secure those apps appropriately for all clients.&#8221;</p>
<p>The decision of how much security is good enough will be made by the SaaS vendor, based on their financial model and risk tolerance, and most of their clients will never realize that their own risk model isn&#8217;t considered except very indirectly.</p>
<p>Likewise, notification of email address exposure shouldn&#8217;t be left to the discretion of the compromised (and thus embarassed) vendor.  Clients of SaaS vendors should include contractual requirements for notification of any breach or compromise, regardless of extent.  It&#8217;s part of the information required to properly evaluate SaaS vendor quality of service.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: arieanna</title>
		<link>http://itknowledgeexchange.techtarget.com/security-bytes/salesforcecom-and-the-debate-over-saas-security-email-confidentiality/#comment-425</link>
		<dc:creator>arieanna</dc:creator>
		<pubDate>Fri, 02 Nov 2007 17:37:48 +0000</pubDate>
		<guid isPermaLink="false">http://security.blogs.techtarget.com/2007/11/02/salesforcecom-and-the-debate-over-saas-security-email-confidentiality/#comment-425</guid>
		<description>Great article. I agree that perhaps vendors can step in and offer a solution to cover data not currently considered confidential. I think that no matter what type of data is breached, it is a hit to credibility. If that data is being used in creative ways by phishers, there is a greater issue of responsibility, not just compliance.</description>
		<content:encoded><![CDATA[<p>Great article. I agree that perhaps vendors can step in and offer a solution to cover data not currently considered confidential. I think that no matter what type of data is breached, it is a hit to credibility. If that data is being used in creative ways by phishers, there is a greater issue of responsibility, not just compliance.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- dynamic -->