<?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: The Spire Vulnerability Rating (VR)</title>
	<atom:link href="http://spiresecurity.com/?feed=rss2&#038;p=244" rel="self" type="application/rss+xml" />
	<link>http://spiresecurity.com/?p=244</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=244&#038;cpage=1#comment-335</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Wed, 28 Nov 2007 18:35:41 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=244#comment-335</guid>
		<description><![CDATA[@DF -

I think it makes complete sense to want to have a good idea about which platforms are more or less vulnerable than others at the earliest possible time in your deployment cycle (e.g. at buying time). To accomplish that objective, you can look at complexity measures (we assume that more complex software is more likely to have more vulnerabilities, though the only study I am aware of didn&#039;t find a correlation) or attack surface measures - e.g. the Relative Attack Surface Quotient (RASQ).

Unfortunately, the complexity work is not simple post production and isn&#039;t published (or isn&#039;t done) during development. So we are stuck with making do with the things we can quantify.

You are right that the VR comparative ratings will change over time and could flip-flop - the whole Firefox vs. IE fiasco of late &#039;04 is a good example of that.

The thing I like about the VR is that you can isolate on exposure and measure trends in your own deployment. There is an element of &quot;threat&quot; in this approach, but I think it will still provide a more useful approach to vulnerability than existing measures.
]]></description>
		<content:encoded><![CDATA[<p>@DF -</p>
<p>I think it makes complete sense to want to have a good idea about which platforms are more or less vulnerable than others at the earliest possible time in your deployment cycle (e.g. at buying time). To accomplish that objective, you can look at complexity measures (we assume that more complex software is more likely to have more vulnerabilities, though the only study I am aware of didn&#8217;t find a correlation) or attack surface measures &#8211; e.g. the Relative Attack Surface Quotient (RASQ).</p>
<p>Unfortunately, the complexity work is not simple post production and isn&#8217;t published (or isn&#8217;t done) during development. So we are stuck with making do with the things we can quantify.</p>
<p>You are right that the VR comparative ratings will change over time and could flip-flop &#8211; the whole Firefox vs. IE fiasco of late &#8217;04 is a good example of that.</p>
<p>The thing I like about the VR is that you can isolate on exposure and measure trends in your own deployment. There is an element of &#8220;threat&#8221; in this approach, but I think it will still provide a more useful approach to vulnerability than existing measures.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anton Chuvakin</title>
		<link>http://spiresecurity.com/?p=244&#038;cpage=1#comment-334</link>
		<dc:creator>Anton Chuvakin</dc:creator>
		<pubDate>Tue, 27 Nov 2007 18:06:31 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=244#comment-334</guid>
		<description><![CDATA[Just sent it to CVSS list....
]]></description>
		<content:encoded><![CDATA[<p>Just sent it to CVSS list&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DF</title>
		<link>http://spiresecurity.com/?p=244&#038;cpage=1#comment-333</link>
		<dc:creator>DF</dc:creator>
		<pubDate>Tue, 27 Nov 2007 15:19:31 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=244#comment-333</guid>
		<description><![CDATA[My question about less actively probed software was not directed to effort metrics, but the phenomena of widely used software attracting more researchers and criminals, while little used or distributed software attracts fewer.  It seems to me that recently released widely used software could initially be rated more vulnerable than little used software, and the ratings could flip over time.  If so, a rating at any point in time does not provide a comparable measure of vulnerability that could be used in purchasing or operational decisions.

Does that make sense, or have I missed something?
]]></description>
		<content:encoded><![CDATA[<p>My question about less actively probed software was not directed to effort metrics, but the phenomena of widely used software attracting more researchers and criminals, while little used or distributed software attracts fewer.  It seems to me that recently released widely used software could initially be rated more vulnerable than little used software, and the ratings could flip over time.  If so, a rating at any point in time does not provide a comparable measure of vulnerability that could be used in purchasing or operational decisions.</p>
<p>Does that make sense, or have I missed something?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete</title>
		<link>http://spiresecurity.com/?p=244&#038;cpage=1#comment-332</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Tue, 27 Nov 2007 14:12:21 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=244#comment-332</guid>
		<description><![CDATA[@DF -

Three great questions that certainly could be asked of vulnerability counts and Days of Risk as well. I&#039;ll take them one at a time.

1) While I fully endorse techniques during development to capture effort metrics, it is extremely difficult to do this for the entire world. The metric does not address discovery effort directly, but it should be reflected in the trend line as higher peaks - i.e. vulns found would have more significant impact.

2)(TD - DOB) in the denominator covers mature vs. new products, since it is a product lifetime (or deployment period for enterprises). New products will divide by a smaller number, so each individual vuln has greater impact. As we expect software to get  more secure over time (else we wouldn&#039;t be looking for vulns) the impact flattens out over time as well.

3) I don&#039;t account for severity. My belief is that a metric should start simple and then get more complex as need arises. If severity levels can be objectively shown to be significantly different among programs with the same general function, then I will come up with a corresponding weighting scheme for each vuln&#039;s lifetime.

Thanks for the comments!

]]></description>
		<content:encoded><![CDATA[<p>@DF -</p>
<p>Three great questions that certainly could be asked of vulnerability counts and Days of Risk as well. I&#8217;ll take them one at a time.</p>
<p>1) While I fully endorse techniques during development to capture effort metrics, it is extremely difficult to do this for the entire world. The metric does not address discovery effort directly, but it should be reflected in the trend line as higher peaks &#8211; i.e. vulns found would have more significant impact.</p>
<p>2)(TD &#8211; DOB) in the denominator covers mature vs. new products, since it is a product lifetime (or deployment period for enterprises). New products will divide by a smaller number, so each individual vuln has greater impact. As we expect software to get  more secure over time (else we wouldn&#8217;t be looking for vulns) the impact flattens out over time as well.</p>
<p>3) I don&#8217;t account for severity. My belief is that a metric should start simple and then get more complex as need arises. If severity levels can be objectively shown to be significantly different among programs with the same general function, then I will come up with a corresponding weighting scheme for each vuln&#8217;s lifetime.</p>
<p>Thanks for the comments!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DF</title>
		<link>http://spiresecurity.com/?p=244&#038;cpage=1#comment-331</link>
		<dc:creator>DF</dc:creator>
		<pubDate>Tue, 27 Nov 2007 12:47:14 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=244#comment-331</guid>
		<description><![CDATA[How does this formula account for software that is less actively probed for vulnerabilities, and software that is mature vs. newly released?

Also, how does it account for differences in vulnerability severity?
]]></description>
		<content:encoded><![CDATA[<p>How does this formula account for software that is less actively probed for vulnerabilities, and software that is mature vs. newly released?</p>
<p>Also, how does it account for differences in vulnerability severity?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
