<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Software Liability Redux</title>
	<atom:link href="http://spiresecurity.com/?feed=rss2&#038;p=350" rel="self" type="application/rss+xml" />
	<link>http://spiresecurity.com/?p=350</link>
	<description>Risk and Cybersecurity Analysis</description>
	<lastBuildDate>Wed, 21 Aug 2013 23:28:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Pete</title>
		<link>http://spiresecurity.com/?p=350&#038;cpage=1#comment-514</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Mon, 22 Jan 2007 18:55:55 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=350#comment-514</guid>
		<description><![CDATA[@TheHawk -

Great comments. Here are some responses:

1) No user would read the SSDS like they might need to for protection from MSDS. This is a manifest for import locally.

2) An SSDS is a hedge against much worse &quot;general liability&quot; for any software. Hopefully, it would forego the need for software liability. To the extent that it doesn&#039;t, costs would be minimized because of the very specific nature of the information available.

3) Every major antivirus vendor already has HIPS built into their product. Since this would take a few product cycles to accomplish anyway, there is no reason the costs for the after-market security products would change.

4) Kurt already addressed the cost of doing business point. I believe anything that is specific and defendable provides a better avenue than what I picture with the ambiguous approach being offered up today.

Hope this clarifies.

]]></description>
		<content:encoded><![CDATA[<p>@TheHawk -</p>
<p>Great comments. Here are some responses:</p>
<p>1) No user would read the SSDS like they might need to for protection from MSDS. This is a manifest for import locally.</p>
<p>2) An SSDS is a hedge against much worse &#8220;general liability&#8221; for any software. Hopefully, it would forego the need for software liability. To the extent that it doesn&#8217;t, costs would be minimized because of the very specific nature of the information available.</p>
<p>3) Every major antivirus vendor already has HIPS built into their product. Since this would take a few product cycles to accomplish anyway, there is no reason the costs for the after-market security products would change.</p>
<p>4) Kurt already addressed the cost of doing business point. I believe anything that is specific and defendable provides a better avenue than what I picture with the ambiguous approach being offered up today.</p>
<p>Hope this clarifies.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kurt wismer</title>
		<link>http://spiresecurity.com/?p=350&#038;cpage=1#comment-513</link>
		<dc:creator>kurt wismer</dc:creator>
		<pubDate>Mon, 22 Jan 2007 16:35:17 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=350#comment-513</guid>
		<description><![CDATA[@thehawk

ultimately if we&#039;re going to wind up with better/more secure code then the organizations producing the code are going to have to do more than they&#039;re doing now and probably spend longer doing it - that alone is going to increase the cost of doing business...

the problem is that there&#039;s insufficient motivation for most organizations to do that so we need a set of motivations to help things along - we need a carrot and we need a stick... software liability is the stick, the get out of software liability (sorta) free card is the carrot...

arguably, the cost of not improving the quality of the code being produced may be greater than the cost of the improvements... that&#039;s the underlying assumption, anyways...
]]></description>
		<content:encoded><![CDATA[<p>@thehawk</p>
<p>ultimately if we&#8217;re going to wind up with better/more secure code then the organizations producing the code are going to have to do more than they&#8217;re doing now and probably spend longer doing it &#8211; that alone is going to increase the cost of doing business&#8230;</p>
<p>the problem is that there&#8217;s insufficient motivation for most organizations to do that so we need a set of motivations to help things along &#8211; we need a carrot and we need a stick&#8230; software liability is the stick, the get out of software liability (sorta) free card is the carrot&#8230;</p>
<p>arguably, the cost of not improving the quality of the code being produced may be greater than the cost of the improvements&#8230; that&#8217;s the underlying assumption, anyways&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TheHawk</title>
		<link>http://spiresecurity.com/?p=350&#038;cpage=1#comment-512</link>
		<dc:creator>TheHawk</dc:creator>
		<pubDate>Mon, 22 Jan 2007 13:33:32 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=350#comment-512</guid>
		<description><![CDATA[Just my 2 pennies.....
Any idea or suggestion must take into account the end user of the idea.  Waltz into your favorite watering hole and ask the bartender if they understand the MSDS sheet for the funny looking/smelling chemical she is spraying in/around your food.  My guess is no.  While the argument that Software Liability benefits only the big companies that could theoretically afford the insurance has potential, how the hell does an SSDS solve that?  The approach, not even half baked, benefits larger consumers that even have host-based IDS/IPS to begin with.  What of the small guy with limited budget, struggling to keep the lights on that has no choice but to rely on vendor (or developer) supplied security controls that may on may not suck (or suck as bad as the next competitor)?  In either manner your talking an increase in the cost of doing business.  As liability costs are baked into the development cycle the market will eventually place competition on them to reduce the cost no?
]]></description>
		<content:encoded><![CDATA[<p>Just my 2 pennies&#8230;..<br />
Any idea or suggestion must take into account the end user of the idea.  Waltz into your favorite watering hole and ask the bartender if they understand the MSDS sheet for the funny looking/smelling chemical she is spraying in/around your food.  My guess is no.  While the argument that Software Liability benefits only the big companies that could theoretically afford the insurance has potential, how the hell does an SSDS solve that?  The approach, not even half baked, benefits larger consumers that even have host-based IDS/IPS to begin with.  What of the small guy with limited budget, struggling to keep the lights on that has no choice but to rely on vendor (or developer) supplied security controls that may on may not suck (or suck as bad as the next competitor)?  In either manner your talking an increase in the cost of doing business.  As liability costs are baked into the development cycle the market will eventually place competition on them to reduce the cost no?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete</title>
		<link>http://spiresecurity.com/?p=350&#038;cpage=1#comment-511</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Fri, 19 Jan 2007 00:55:31 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=350#comment-511</guid>
		<description><![CDATA[@Gunnar -

The food label approach is a useful one - I am definitely a fan of objective metrics that describe software complexity. But the SSDS isn&#039;t a set of numbers, it is a full-blown policy that can be used to allow/deny program operations.
]]></description>
		<content:encoded><![CDATA[<p>@Gunnar -</p>
<p>The food label approach is a useful one &#8211; I am definitely a fan of objective metrics that describe software complexity. But the SSDS isn&#8217;t a set of numbers, it is a full-blown policy that can be used to allow/deny program operations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gunnar</title>
		<link>http://spiresecurity.com/?p=350&#038;cpage=1#comment-510</link>
		<dc:creator>Gunnar</dc:creator>
		<pubDate>Thu, 18 Jan 2007 22:49:52 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=350#comment-510</guid>
		<description><![CDATA[Yep, SSDS approach is the way to go. Here is an example, via Jeff Williams&#039; OWASP presentation awhile back

http://1raindrop.typepad.com/1_raindrop/2005/04/owasp_europe_wr.html
]]></description>
		<content:encoded><![CDATA[<p>Yep, SSDS approach is the way to go. Here is an example, via Jeff Williams&#8217; OWASP presentation awhile back</p>
<p><a href="http://1raindrop.typepad.com/1_raindrop/2005/04/owasp_europe_wr.html" rel="nofollow">http://1raindrop.typepad.com/1_raindrop/2005/04/owasp_europe_wr.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete</title>
		<link>http://spiresecurity.com/?p=350&#038;cpage=1#comment-509</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Thu, 18 Jan 2007 19:27:36 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=350#comment-509</guid>
		<description><![CDATA[@Kurt -

&quot;slapping the developer in the face is going after the wrong person, though... &quot;

That&#039;s my point - I believe folks who support software liability are slapping developers, not me.

Re: immunity from liability

I think of this like (I believe) the v-chip brouhaha went in the television world - self-governance trumping government interference that would inevitably turn out poorly. I think your idea is a great one, to combine the two.
]]></description>
		<content:encoded><![CDATA[<p>@Kurt -</p>
<p>&#8220;slapping the developer in the face is going after the wrong person, though&#8230; &#8221;</p>
<p>That&#8217;s my point &#8211; I believe folks who support software liability are slapping developers, not me.</p>
<p>Re: immunity from liability</p>
<p>I think of this like (I believe) the v-chip brouhaha went in the television world &#8211; self-governance trumping government interference that would inevitably turn out poorly. I think your idea is a great one, to combine the two.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kurt wismer</title>
		<link>http://spiresecurity.com/?p=350&#038;cpage=1#comment-508</link>
		<dc:creator>kurt wismer</dc:creator>
		<pubDate>Thu, 18 Jan 2007 19:20:08 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=350#comment-508</guid>
		<description><![CDATA[slapping the developer in the face is going after the wrong person, though... from my own experience, business decisions corrupt the integrity of the software development process... business decisions aren&#039;t usually made by the developers...

software security data sheets may be a good idea in theory, but there&#039;s one advantage schneier&#039;s idea has over yours - it deals with the problem of inertia... you haven&#039;t proposed anything that would change the business equation enough to make companies want to create software security data sheets...

how about a compromise - make it so that the ssds gives companies immunity against liability... if you don&#039;t do X you &#039;may&#039; be held liable for problems in your software...
]]></description>
		<content:encoded><![CDATA[<p>slapping the developer in the face is going after the wrong person, though&#8230; from my own experience, business decisions corrupt the integrity of the software development process&#8230; business decisions aren&#8217;t usually made by the developers&#8230;</p>
<p>software security data sheets may be a good idea in theory, but there&#8217;s one advantage schneier&#8217;s idea has over yours &#8211; it deals with the problem of inertia&#8230; you haven&#8217;t proposed anything that would change the business equation enough to make companies want to create software security data sheets&#8230;</p>
<p>how about a compromise &#8211; make it so that the ssds gives companies immunity against liability&#8230; if you don&#8217;t do X you &#8216;may&#8217; be held liable for problems in your software&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
