<?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: Response to Schneier on Full Disclosure</title>
	<atom:link href="http://spiresecurity.com/?feed=rss2&#038;p=139" rel="self" type="application/rss+xml" />
	<link>http://spiresecurity.com/?p=139</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: Michael Bennett</title>
		<link>http://spiresecurity.com/?p=139&#038;cpage=1#comment-150</link>
		<dc:creator>Michael Bennett</dc:creator>
		<pubDate>Tue, 23 Sep 2008 13:47:55 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=139#comment-150</guid>
		<description><![CDATA[Interesting comments. I&#039;m not wanting to get into a discussion on full disclosure, so I&#039;ll just add my 2c worth on probability and risk.

Only a small fraction of vulnerabilities are found because only a small fraction of code is analysed. Vulnerabilities are not discrete entities, they almost always fall into a class of vulnerability that is known and some of these classes are easier to test for or exploit. It is likely that two people will come up with the same or substantially similar vulnerabilities because easiest will be tried first.

In terms of risk, the probability of compromise is 1. The statistics come from how severe and how frequent the compromises are. This results in a minimisation methodology where as long as the overall loss remains at an tolerable level then the leakage is accepted. If only 1 person exploited the vulnerability, it would never be known. If a gang exploited the vulnerability, it would eventually become known, police would be called, they would eventually be caught, and the vulnerability would be found out then patched in the next release or two. If the method of exploitation is made public then the overall level of loss may quickly become uncontrolled. This gets fixed quickly.

Security is not the opposite of shoddy design. While a good design can remove and reduce vulnerabilities, security can never be perfect. The best that can be hoped for is striving for excellence in design and implementation and an iterative approach to resolving problems.
]]></description>
		<content:encoded><![CDATA[<p>Interesting comments. I&#8217;m not wanting to get into a discussion on full disclosure, so I&#8217;ll just add my 2c worth on probability and risk.</p>
<p>Only a small fraction of vulnerabilities are found because only a small fraction of code is analysed. Vulnerabilities are not discrete entities, they almost always fall into a class of vulnerability that is known and some of these classes are easier to test for or exploit. It is likely that two people will come up with the same or substantially similar vulnerabilities because easiest will be tried first.</p>
<p>In terms of risk, the probability of compromise is 1. The statistics come from how severe and how frequent the compromises are. This results in a minimisation methodology where as long as the overall loss remains at an tolerable level then the leakage is accepted. If only 1 person exploited the vulnerability, it would never be known. If a gang exploited the vulnerability, it would eventually become known, police would be called, they would eventually be caught, and the vulnerability would be found out then patched in the next release or two. If the method of exploitation is made public then the overall level of loss may quickly become uncontrolled. This gets fixed quickly.</p>
<p>Security is not the opposite of shoddy design. While a good design can remove and reduce vulnerabilities, security can never be perfect. The best that can be hoped for is striving for excellence in design and implementation and an iterative approach to resolving problems.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
