<?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: H1N1 Threat Overblown? Information Security Relevance? A Logic Proof</title>
	<atom:link href="http://www.bloginfosec.com/2010/01/27/h1n1-threat-overblown-information-security-relevance-a-logic-proof/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bloginfosec.com/2010/01/27/h1n1-threat-overblown-information-security-relevance-a-logic-proof/</link>
	<description>An Information Security Magazine in a Blog Format</description>
	<lastBuildDate>Mon, 30 Jan 2012 11:01:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Kenneth F. Belva</title>
		<link>http://www.bloginfosec.com/2010/01/27/h1n1-threat-overblown-information-security-relevance-a-logic-proof/comment-page-1/#comment-20397</link>
		<dc:creator>Kenneth F. Belva</dc:creator>
		<pubDate>Thu, 23 Sep 2010 20:03:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.bloginfosec.com/?p=1291#comment-20397</guid>
		<description>Hi Dave,

Thanks for commenting.

While I agree that having more precise numbers will help in policy and decision making, I disagree with you that it&#039;s something that must be present in all cases (and in this case H1N1).

There are plenty of times we assess a risk without being able to assign a specific quantified number. For example, build an old Windows 2000 server from the original distribution disk and leave it unpatched. Then connect it to the internet directly. Can you truly give me a quantitative measurement of _exactly_ when it will be compromised? What are the exact chances of compromise in the first minute? What about 5? 10? 30? Hour? We certainly can give a qualified description of what will happen: the longer we leave the box out there the more likely it will be hacked. In addition, since the flaws are so well known with many published exploits we expect this compromise to be almost guaranteed since the server is low-hanging fruit.

The same goes for H1N1. Can we really construct quantitative metrics for emergence of a new virus? Unlikely. Since scientists know the properties of the virus they may be able to give us an accurate qualitative description of the risks. We can then take concrete measures to reduce the risks are they are described.

In life we make most of our decisions without the aid of mathematical precision. We shouldn&#039;t let this fact become a handicap when understanding risk related matters, including those in our field of information security.</description>
		<content:encoded><![CDATA[<p>Hi Dave,</p>
<p>Thanks for commenting.</p>
<p>While I agree that having more precise numbers will help in policy and decision making, I disagree with you that it&#8217;s something that must be present in all cases (and in this case H1N1).</p>
<p>There are plenty of times we assess a risk without being able to assign a specific quantified number. For example, build an old Windows 2000 server from the original distribution disk and leave it unpatched. Then connect it to the internet directly. Can you truly give me a quantitative measurement of _exactly_ when it will be compromised? What are the exact chances of compromise in the first minute? What about 5? 10? 30? Hour? We certainly can give a qualified description of what will happen: the longer we leave the box out there the more likely it will be hacked. In addition, since the flaws are so well known with many published exploits we expect this compromise to be almost guaranteed since the server is low-hanging fruit.</p>
<p>The same goes for H1N1. Can we really construct quantitative metrics for emergence of a new virus? Unlikely. Since scientists know the properties of the virus they may be able to give us an accurate qualitative description of the risks. We can then take concrete measures to reduce the risks are they are described.</p>
<p>In life we make most of our decisions without the aid of mathematical precision. We shouldn&#8217;t let this fact become a handicap when understanding risk related matters, including those in our field of information security.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Funk</title>
		<link>http://www.bloginfosec.com/2010/01/27/h1n1-threat-overblown-information-security-relevance-a-logic-proof/comment-page-1/#comment-20396</link>
		<dc:creator>Dave Funk</dc:creator>
		<pubDate>Thu, 23 Sep 2010 19:29:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.bloginfosec.com/?p=1291#comment-20396</guid>
		<description>The problem with &quot;We changed the environment so that it would be much less likely to happen.”  is also logically flawed.  Yes the environment was change but what was the change in the probability?  Unfortunately in both the cases discussed here, we have no idea what either the before or the after probability was/is.  It is very possible (no idea the probability) that with the H1N1 the probability of a pandemic with 2 million dead was 7% and after the work put in to mitigate the impact the probability of the same pandemic was reduced to 6.5%.  If we knew these numbers we could rationally deconstruct and decide how much money it makes sense to spend.  If we do not, we are left with other questions, like who is asking us to spend the money and what is in it for them.  This is why the FUD argument is so dangerous for the security professional.</description>
		<content:encoded><![CDATA[<p>The problem with &#8220;We changed the environment so that it would be much less likely to happen.”  is also logically flawed.  Yes the environment was change but what was the change in the probability?  Unfortunately in both the cases discussed here, we have no idea what either the before or the after probability was/is.  It is very possible (no idea the probability) that with the H1N1 the probability of a pandemic with 2 million dead was 7% and after the work put in to mitigate the impact the probability of the same pandemic was reduced to 6.5%.  If we knew these numbers we could rationally deconstruct and decide how much money it makes sense to spend.  If we do not, we are left with other questions, like who is asking us to spend the money and what is in it for them.  This is why the FUD argument is so dangerous for the security professional.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave R</title>
		<link>http://www.bloginfosec.com/2010/01/27/h1n1-threat-overblown-information-security-relevance-a-logic-proof/comment-page-1/#comment-20283</link>
		<dc:creator>Dave R</dc:creator>
		<pubDate>Wed, 27 Jan 2010 13:07:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.bloginfosec.com/?p=1291#comment-20283</guid>
		<description>The Y2K effort (now a full ten years ago, can you believe it) is perhaps the most famous illustration of Ken’s point.

Y2K was a “non-event” and a “wasted effort” and a “false alarm” in the minds of many people.

Put aside entirely the absurd Y2K alarmists’ fears and predictions of world-wide technological collapse.  No rational technologist accepted or believed these predictions anyway.

The fact is that there were real, genuine date-related “bugs” in our systems.  They were pervasive, potentially disruptive and possibly ruinous for the conduct of business if ignored.  We did not ignore them, we spent a couple of years finding and fixing them.  Practitioners who know the extent of the remediation understand that it was necessary and appropriate, and that it was just in time -- we could not wait until January 1, 2000 to begin to address the problem.

But in retrospect, because on that date there was no Y2K disaster, there are still people who believe to this day -- with false logic -- that the entire matter was a hoax.</description>
		<content:encoded><![CDATA[<p>The Y2K effort (now a full ten years ago, can you believe it) is perhaps the most famous illustration of Ken’s point.</p>
<p>Y2K was a “non-event” and a “wasted effort” and a “false alarm” in the minds of many people.</p>
<p>Put aside entirely the absurd Y2K alarmists’ fears and predictions of world-wide technological collapse.  No rational technologist accepted or believed these predictions anyway.</p>
<p>The fact is that there were real, genuine date-related “bugs” in our systems.  They were pervasive, potentially disruptive and possibly ruinous for the conduct of business if ignored.  We did not ignore them, we spent a couple of years finding and fixing them.  Practitioners who know the extent of the remediation understand that it was necessary and appropriate, and that it was just in time &#8212; we could not wait until January 1, 2000 to begin to address the problem.</p>
<p>But in retrospect, because on that date there was no Y2K disaster, there are still people who believe to this day &#8212; with false logic &#8212; that the entire matter was a hoax.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

