<?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: Why Bugfinding is Irresponsible and Increases Risk</title>
	<atom:link href="http://spiresecurity.com/?feed=rss2&#038;p=449" rel="self" type="application/rss+xml" />
	<link>http://spiresecurity.com/?p=449</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: Security Curve Weblog</title>
		<link>http://spiresecurity.com/?p=449&#038;cpage=1#comment-733</link>
		<dc:creator>Security Curve Weblog</dc:creator>
		<pubDate>Tue, 13 Jun 2006 14:11:57 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=449#comment-733</guid>
		<description><![CDATA[&lt;strong&gt;Rethinking full-dislosure...&lt;/strong&gt;

This morning I noticed that McAfee announced yesterday that they fully intend to once again enter the game of public vulnerability disclosure. Now, as you may or may not know, I&#039;m a huge fan of full-disclsure; given my belief that full-disclosure is a ...
]]></description>
		<content:encoded><![CDATA[<p><strong>Rethinking full-dislosure&#8230;</strong></p>
<p>This morning I noticed that McAfee announced yesterday that they fully intend to once again enter the game of public vulnerability disclosure. Now, as you may or may not know, I&#8217;m a huge fan of full-disclsure; given my belief that full-disclosure is a &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: another pete</title>
		<link>http://spiresecurity.com/?p=449&#038;cpage=1#comment-732</link>
		<dc:creator>another pete</dc:creator>
		<pubDate>Fri, 31 Mar 2006 13:19:37 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=449#comment-732</guid>
		<description><![CDATA[If the software vendors become the authority over disclosure then will they do the right thing and promptly fix the problem, recall the software, or notify consumers in a grand and public way?  History shows us that they do not.  A certain percentage of bug hunters (I don&#039;t know any studies but I know those who are) are in it for the gold and the glory. They do it for the same business reasons that the software vendors do NOT disclose.  The current model doesn&#039;t have to be.  It is a cumulation of frustration since the vendors consistently do NOT do the right thing.

Furthermore, there exists a new market to sell disclosure to those who can pay regardless of intentions.  Like any criminal activity, this is a natural process.  Pete refers to the natural process of development to discovered vulnerabilty that researchers are disturbing.  It never was a natural process.  Someone has to actively look for most bugs and then consider implications/payload/process before it becomes a verifiable problem.  So whether it be the misguided evolution of penetration testing to force researchers to add 0-days to their bag of tricks (to earn more money) or sec researchers looking for bugs for money or attention the process has always been forced.

As the issue now stands, it is unfixable through &quot;responsible disclosure&quot;.  The market has been made. Anyone with a debugger and a fuzzer stands to make something of themselves one way or another.  Even 3rd party &quot;IDS/IPS/FW/Anti-Virus/Bogus Powdered Spit Protection&quot; wants a share of the cash.  Some of them are the same vendors who sell the buggy software to start with.  The capitalistic forces in this market segment are overwhelming and the disclosure debate is no more than a form of idleness.  There can only be one way forward here and that&#039;s to close the loop-- vendors need to stop releasing bad software WITHOUT warranty/responsibility/reliability.

How do we get there?  Disclosure.  It&#039;s a force that has existed as long as humans have been social creatures living in communities.  We share the scary stuff with each other through song, dance, or recently, words, and try to help our neighbors by making them aware so they can help watch out with us. Secrets of pain are only hurtful to ourselves in the long run.
]]></description>
		<content:encoded><![CDATA[<p>If the software vendors become the authority over disclosure then will they do the right thing and promptly fix the problem, recall the software, or notify consumers in a grand and public way?  History shows us that they do not.  A certain percentage of bug hunters (I don&#8217;t know any studies but I know those who are) are in it for the gold and the glory. They do it for the same business reasons that the software vendors do NOT disclose.  The current model doesn&#8217;t have to be.  It is a cumulation of frustration since the vendors consistently do NOT do the right thing.</p>
<p>Furthermore, there exists a new market to sell disclosure to those who can pay regardless of intentions.  Like any criminal activity, this is a natural process.  Pete refers to the natural process of development to discovered vulnerabilty that researchers are disturbing.  It never was a natural process.  Someone has to actively look for most bugs and then consider implications/payload/process before it becomes a verifiable problem.  So whether it be the misguided evolution of penetration testing to force researchers to add 0-days to their bag of tricks (to earn more money) or sec researchers looking for bugs for money or attention the process has always been forced.</p>
<p>As the issue now stands, it is unfixable through &#8220;responsible disclosure&#8221;.  The market has been made. Anyone with a debugger and a fuzzer stands to make something of themselves one way or another.  Even 3rd party &#8220;IDS/IPS/FW/Anti-Virus/Bogus Powdered Spit Protection&#8221; wants a share of the cash.  Some of them are the same vendors who sell the buggy software to start with.  The capitalistic forces in this market segment are overwhelming and the disclosure debate is no more than a form of idleness.  There can only be one way forward here and that&#8217;s to close the loop&#8211; vendors need to stop releasing bad software WITHOUT warranty/responsibility/reliability.</p>
<p>How do we get there?  Disclosure.  It&#8217;s a force that has existed as long as humans have been social creatures living in communities.  We share the scary stuff with each other through song, dance, or recently, words, and try to help our neighbors by making them aware so they can help watch out with us. Secrets of pain are only hurtful to ourselves in the long run.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert E. Lee</title>
		<link>http://spiresecurity.com/?p=449&#038;cpage=1#comment-731</link>
		<dc:creator>Robert E. Lee</dc:creator>
		<pubDate>Sat, 25 Mar 2006 20:17:39 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=449#comment-731</guid>
		<description><![CDATA[@Anonymous

&gt; You both make the case that the effort should be on protecting systems and data from all vulnerabilities at either o/s or app level.

I took care to change that claim from all vulnerabilities to entire classes of vulnerabilities.  Anyone who is claiming to protect against all known and unknown problems is obviously selling you something.

A trusted base is the starting point, but covers well more than the OS itself.  You have to start with the hardware and build up the trust of your base from there.

Even with SE Linux installed with a well thought out policy, application level flaws could lead to Confidentiality and Integrity faults depending on how well the application code was written.  IE, SQL injection would still be possible, but you wouldn&#039;t be able to &quot;pop a shell&quot;.

As we both more or less said previously, moving towards a trusted model, we&#039;d still have the need to find, track, and fix vulnerabilities, but the game would be different from the standpoint that most of them would be mitigated by our policies, instead of having to frantically install patches.

If you&#039;re really interested in this stuff, irc on the efnet network and join #selinux.  We can talk in detail about trusted computing there.

Robert
]]></description>
		<content:encoded><![CDATA[<p>@Anonymous</p>
<p>> You both make the case that the effort should be on protecting systems and data from all vulnerabilities at either o/s or app level.</p>
<p>I took care to change that claim from all vulnerabilities to entire classes of vulnerabilities.  Anyone who is claiming to protect against all known and unknown problems is obviously selling you something.</p>
<p>A trusted base is the starting point, but covers well more than the OS itself.  You have to start with the hardware and build up the trust of your base from there.</p>
<p>Even with SE Linux installed with a well thought out policy, application level flaws could lead to Confidentiality and Integrity faults depending on how well the application code was written.  IE, SQL injection would still be possible, but you wouldn&#8217;t be able to &#8220;pop a shell&#8221;.</p>
<p>As we both more or less said previously, moving towards a trusted model, we&#8217;d still have the need to find, track, and fix vulnerabilities, but the game would be different from the standpoint that most of them would be mitigated by our policies, instead of having to frantically install patches.</p>
<p>If you&#8217;re really interested in this stuff, irc on the efnet network and join #selinux.  We can talk in detail about trusted computing there.</p>
<p>Robert</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://spiresecurity.com/?p=449&#038;cpage=1#comment-730</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Sat, 25 Mar 2006 18:22:04 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=449#comment-730</guid>
		<description><![CDATA[The Windows certification was basically a joke and useful only for marketing and publicity ploys, seeing how the system tested was not connected to the internet, was to have no floppy drive and was to run only limited applications, if any, (the way I heard it anyway).

You both make the case that the effort should be on protecting systems and data from all vulnerabilities at either o/s or app level. When that happens, the glory for successfully writing a worm or virus, (from the cracker side) or for finding a vulnerability(from the bug finder side), will fade to zero, right?

Since this level of protection can only occur on the host, does this lead to a natural conclusion that we should be looking at trusted operating systems?

If this would be achievable, then the vulnerabilities would still exist, they would just not be useable to escalate privileges. Does this mean that the risk and threat models would change, as no vulnerability would be used to become a threat and risk would then become zero?
]]></description>
		<content:encoded><![CDATA[<p>The Windows certification was basically a joke and useful only for marketing and publicity ploys, seeing how the system tested was not connected to the internet, was to have no floppy drive and was to run only limited applications, if any, (the way I heard it anyway).</p>
<p>You both make the case that the effort should be on protecting systems and data from all vulnerabilities at either o/s or app level. When that happens, the glory for successfully writing a worm or virus, (from the cracker side) or for finding a vulnerability(from the bug finder side), will fade to zero, right?</p>
<p>Since this level of protection can only occur on the host, does this lead to a natural conclusion that we should be looking at trusted operating systems?</p>
<p>If this would be achievable, then the vulnerabilities would still exist, they would just not be useable to escalate privileges. Does this mean that the risk and threat models would change, as no vulnerability would be used to become a threat and risk would then become zero?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete</title>
		<link>http://spiresecurity.com/?p=449&#038;cpage=1#comment-729</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Sat, 25 Mar 2006 02:30:27 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=449#comment-729</guid>
		<description><![CDATA[&gt;REL: We&#039;re more similar than you think. I have the same opinion about &gt;IDS/IPS/FW/Anti-Virus/Bogus Powdered Spit Protection. They do nothing to protect &gt;us from the real threats that are out there - they simply distracts us from doing &gt;so. I&#039;m not arguing the merrits of active vs passive bug finding. Rather my &gt;initial comments were directed at the right to disclose or not to disclose.

Whoa, I neither said anything like that nor believe anything like that, so we must be much different than you think. Inline security solutions are the only ones that can quickly protect us from the logical extension of the damage you are doing. We&#039;d be even more helpless without them.
]]></description>
		<content:encoded><![CDATA[<p>>REL: We&#8217;re more similar than you think. I have the same opinion about >IDS/IPS/FW/Anti-Virus/Bogus Powdered Spit Protection. They do nothing to protect >us from the real threats that are out there &#8211; they simply distracts us from doing >so. I&#8217;m not arguing the merrits of active vs passive bug finding. Rather my >initial comments were directed at the right to disclose or not to disclose.</p>
<p>Whoa, I neither said anything like that nor believe anything like that, so we must be much different than you think. Inline security solutions are the only ones that can quickly protect us from the logical extension of the damage you are doing. We&#8217;d be even more helpless without them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert E. Lee</title>
		<link>http://spiresecurity.com/?p=449&#038;cpage=1#comment-728</link>
		<dc:creator>Robert E. Lee</dc:creator>
		<pubDate>Sat, 25 Mar 2006 02:03:28 +0000</pubDate>
		<guid isPermaLink="false">http://spiresecurity.com/blog/?p=449#comment-728</guid>
		<description><![CDATA[&gt;    1. We’ll never find all the vulnerabilities in existence. This means we can focus on the select few (as many as they are) found by the good guys or come up with a new approach that appropriately addresses all vulnerabilities equally, instead of the ones that some particular bugfinder would like to advance as important simply because s/he found it.

Most of the bugs we find are found while we&#039;re testing customers for other bugs.  I think part of our postions overlap in the fact that we both view the practice of actively looking for new bugs for the sole sake of finding new bugs as a distraction from more important things.  I support the development of technologies that take advantage of security mechanisms that have been proven effective.

I&#039;m not sure what you mean by all treated equally.  The criticality of a bug should be something an end user determines, not a researcher.  As a researcher, all we care to share is the category of problem, what it&#039;s likely to affect (CIA), etc.  High/Medium/Low depends on the organizations pain thressholds for being affected.

&gt; Our goal should be to protect ourselves not from the individual vulns found as they are found, but to protect ourselves from all vulnerabilities all of the time, by taking an architectural view.

Ok, on this particular point, we are definitely in agreement, I just see it as an &quot;and&quot;, not an &quot;or&quot; to the disclosure discussion.

&gt; Vulnerabilities would still be found and we would still provide protection, but the process would be different.

I think I said it in my last post.  The &quot;find a bug&quot;, &quot;disclose a bug&quot;, &quot;patch a bug&quot; game is ultimately fruitless unless it increases the number of consumers who demand technology that will let them &quot;protect [them]selves from [entire classes of] vulnerabilities all of the time, by taking an architectural view&quot;

&gt; A competent organization should be protecting themselves from today’s, tomorrow’s, and next year’s vulnerabilities. Why don’t you want them to do that?

That is our goal, but customers using technology that was only intended to be used in cooperative non-hostile environments, on the internet, are going to have problems.  No firewall/IPS/Anti-Virus is going to change that.

&gt; Windows is Common Criteria certified. Vulnerabilities are inevitable.

It is, you are correct, but look at the Protection Profile selected (CAPP).  The Controlled Access Protection Profile was intended for non-hostile, cooperative environments.  Basically the assurance level matters more if they had tried for better security controls.  When windows achives CC evaluation with LSPP, then it will be more interesting.  If you read the Security Target for windows, you&#039;ll see that the security mechanisms wern&#039;t meant to protect you from bad people on the internet.

Windows 2003 Security Target: http://niap.nist.gov/cc-scheme/st/ST_VID4025-ST.pdf
Windows 2003 Evaluation Report: http://niap.nist.gov/cc-scheme/st/ST_VID4025-VR.pdf

Trusted Solaris 8 Security Target: http://www.commoncriteriaportal.org/public/files/epfiles/TSolaris8_Issue3.1.pdf
Trusted Solaris 8 Security Evaluation Report: http://www.commoncriteriaportal.org/public/files/epfiles/CRP170v3.pdf

To summarize the Strength of Environment for the two...

Windows: The evaluation of Windows 2003/XP provides a moderate level of independently assured security in a
conventional TOE and is suitable for the environment specification in this ST.  Translated - This will work pretty well in a cooperative, non-hostile environment.

TSOL: Trusted Solaris 8 4/01 is intended for use in organisations who need to safeguard
sensitive information (e.g., organisations concerned with processing commercially
sensitive or classified information) and who require security features unavailable
in standard commercial operating environments.

Neither can make a &quot;bug free&quot; claim, but the second one tries to deliver technology that lets a consumer &quot;protect [them]selves from [entire classes of] vulnerabilities all of the time, by taking an architectural view&quot;.

&gt; Make no mistake, what you are doing does nothing to protect us from the real threats that are out there – it simply distracts us from doing so.

We&#039;re more similar than you think.  I have the same opinion about IDS/IPS/FW/Anti-Virus/Bogus Powdered Spit Protection.  They do nothing to protect us from the real threats that are out there - they simply distracts us from doing so.  I&#039;m not arguing the merrits of active vs passive bug finding.  Rather my initial comments were directed at the right to disclose or not to disclose.

Robert
]]></description>
		<content:encoded><![CDATA[<p>>    1. We’ll never find all the vulnerabilities in existence. This means we can focus on the select few (as many as they are) found by the good guys or come up with a new approach that appropriately addresses all vulnerabilities equally, instead of the ones that some particular bugfinder would like to advance as important simply because s/he found it.</p>
<p>Most of the bugs we find are found while we&#8217;re testing customers for other bugs.  I think part of our postions overlap in the fact that we both view the practice of actively looking for new bugs for the sole sake of finding new bugs as a distraction from more important things.  I support the development of technologies that take advantage of security mechanisms that have been proven effective.</p>
<p>I&#8217;m not sure what you mean by all treated equally.  The criticality of a bug should be something an end user determines, not a researcher.  As a researcher, all we care to share is the category of problem, what it&#8217;s likely to affect (CIA), etc.  High/Medium/Low depends on the organizations pain thressholds for being affected.</p>
<p>> Our goal should be to protect ourselves not from the individual vulns found as they are found, but to protect ourselves from all vulnerabilities all of the time, by taking an architectural view.</p>
<p>Ok, on this particular point, we are definitely in agreement, I just see it as an &#8220;and&#8221;, not an &#8220;or&#8221; to the disclosure discussion.</p>
<p>> Vulnerabilities would still be found and we would still provide protection, but the process would be different.</p>
<p>I think I said it in my last post.  The &#8220;find a bug&#8221;, &#8220;disclose a bug&#8221;, &#8220;patch a bug&#8221; game is ultimately fruitless unless it increases the number of consumers who demand technology that will let them &#8220;protect [them]selves from [entire classes of] vulnerabilities all of the time, by taking an architectural view&#8221;</p>
<p>> A competent organization should be protecting themselves from today’s, tomorrow’s, and next year’s vulnerabilities. Why don’t you want them to do that?</p>
<p>That is our goal, but customers using technology that was only intended to be used in cooperative non-hostile environments, on the internet, are going to have problems.  No firewall/IPS/Anti-Virus is going to change that.</p>
<p>> Windows is Common Criteria certified. Vulnerabilities are inevitable.</p>
<p>It is, you are correct, but look at the Protection Profile selected (CAPP).  The Controlled Access Protection Profile was intended for non-hostile, cooperative environments.  Basically the assurance level matters more if they had tried for better security controls.  When windows achives CC evaluation with LSPP, then it will be more interesting.  If you read the Security Target for windows, you&#8217;ll see that the security mechanisms wern&#8217;t meant to protect you from bad people on the internet.</p>
<p>Windows 2003 Security Target: <a href="http://niap.nist.gov/cc-scheme/st/ST_VID4025-ST.pdf" rel="nofollow">http://niap.nist.gov/cc-scheme/st/ST_VID4025-ST.pdf</a><br />
Windows 2003 Evaluation Report: <a href="http://niap.nist.gov/cc-scheme/st/ST_VID4025-VR.pdf" rel="nofollow">http://niap.nist.gov/cc-scheme/st/ST_VID4025-VR.pdf</a></p>
<p>Trusted Solaris 8 Security Target: <a href="http://www.commoncriteriaportal.org/public/files/epfiles/TSolaris8_Issue3.1.pdf" rel="nofollow">http://www.commoncriteriaportal.org/public/files/epfiles/TSolaris8_Issue3.1.pdf</a><br />
Trusted Solaris 8 Security Evaluation Report: <a href="http://www.commoncriteriaportal.org/public/files/epfiles/CRP170v3.pdf" rel="nofollow">http://www.commoncriteriaportal.org/public/files/epfiles/CRP170v3.pdf</a></p>
<p>To summarize the Strength of Environment for the two&#8230;</p>
<p>Windows: The evaluation of Windows 2003/XP provides a moderate level of independently assured security in a<br />
conventional TOE and is suitable for the environment specification in this ST.  Translated &#8211; This will work pretty well in a cooperative, non-hostile environment.</p>
<p>TSOL: Trusted Solaris 8 4/01 is intended for use in organisations who need to safeguard<br />
sensitive information (e.g., organisations concerned with processing commercially<br />
sensitive or classified information) and who require security features unavailable<br />
in standard commercial operating environments.</p>
<p>Neither can make a &#8220;bug free&#8221; claim, but the second one tries to deliver technology that lets a consumer &#8220;protect [them]selves from [entire classes of] vulnerabilities all of the time, by taking an architectural view&#8221;.</p>
<p>> Make no mistake, what you are doing does nothing to protect us from the real threats that are out there – it simply distracts us from doing so.</p>
<p>We&#8217;re more similar than you think.  I have the same opinion about IDS/IPS/FW/Anti-Virus/Bogus Powdered Spit Protection.  They do nothing to protect us from the real threats that are out there &#8211; they simply distracts us from doing so.  I&#8217;m not arguing the merrits of active vs passive bug finding.  Rather my initial comments were directed at the right to disclose or not to disclose.</p>
<p>Robert</p>
]]></content:encoded>
	</item>
</channel>
</rss>
