<?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: 2009 DBIR: Conclusions and recommendations</title>
	<atom:link href="http://securityblog.verizonbusiness.com/2009/04/14/2009-dbir-conclusions-and-recommendations/feed/" rel="self" type="application/rss+xml" />
	<link>http://securityblog.verizonbusiness.com/2009/04/14/2009-dbir-conclusions-and-recommendations/</link>
	<description>Risk Intelligence from Verizon Business Security Solutions powered by Cybertrust</description>
	<lastBuildDate>Fri, 30 Oct 2009 23:27:39 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Patrick Florer</title>
		<link>http://securityblog.verizonbusiness.com/2009/04/14/2009-dbir-conclusions-and-recommendations/comment-page-1/#comment-298</link>
		<dc:creator>Patrick Florer</dc:creator>
		<pubDate>Sun, 19 Apr 2009 01:05:51 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=190#comment-298</guid>
		<description>Nice to hear from you, Alex!

Two follow-up questions:

1)  Are there any large outliers skewing the financial services data?  If so, can you reveal how big they are in terms of breached records?  Would you consider doing a follow-up analysis that excluded these outliers, if they exist?

2)  The report states that 81% of breached companies were not PCI compliant.  Maybe it&#039;s in the report, but I don&#039;t remember seeing it, so can you provide the denominator for PCI related breaches?  all 90?  or something less, as I expect.

I am well - playing too much tennis - the weather in Dallas, though extremely windy at times, is starting to be very nice.

Patrick</description>
		<content:encoded><![CDATA[<p>Nice to hear from you, Alex!</p>
<p>Two follow-up questions:</p>
<p>1)  Are there any large outliers skewing the financial services data?  If so, can you reveal how big they are in terms of breached records?  Would you consider doing a follow-up analysis that excluded these outliers, if they exist?</p>
<p>2)  The report states that 81% of breached companies were not PCI compliant.  Maybe it&#8217;s in the report, but I don&#8217;t remember seeing it, so can you provide the denominator for PCI related breaches?  all 90?  or something less, as I expect.</p>
<p>I am well &#8211; playing too much tennis &#8211; the weather in Dallas, though extremely windy at times, is starting to be very nice.</p>
<p>Patrick</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Hutton</title>
		<link>http://securityblog.verizonbusiness.com/2009/04/14/2009-dbir-conclusions-and-recommendations/comment-page-1/#comment-291</link>
		<dc:creator>Alex Hutton</dc:creator>
		<pubDate>Fri, 17 Apr 2009 18:54:55 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=190#comment-291</guid>
		<description>Hey Patrick!

&quot;If you are not a financial services company, then the question for me becomes “Why not play the odds?” Per your report, only 5% of records breached occurred at non-financial sector companies.&quot;

C&#039;mon now, after all the time we&#039;ve spent together I know you know better.  That number isn&#039;t number of breaches, it is number of records - and the risk tolerance of an organization isn&#039;t set on just number of records (although record number is one informative prior in my mind) it&#039;s every bucket of probable losses (back to FAIR training).  That said, further analysis might warrant &quot;playing the odds&quot; (though I&#039;m guessing fines/judgments might convince you otherwise).

&quot;And, there are so many other useful correlations that you could present (Alex, are you listening?&quot;

I assure you I&#039;m listening.  And I agree that there should be more fun to follow.  But we have multiple factors to weigh here, not the least of which is releasing a report that is digestible in length.  Nobody wants a TLDNR tome of arcane statistical analysis, but the depth of the initial (there I said it, initial) analysis had to be established at some level - we chose the one you see in the report.  My goal is to develop subsequent analysis that goes deeper where we can find useful information (see my upcoming post on Timespan of Breach Events as an example).

That said we can&#039;t make some numbers appear out of thin air (nor would you want us to).  &quot;The most important, and certainly the most difficult metric, would be, what’s the impact ($$$) of a given attack?&quot;  Impact measurements, for example, are not in scope for Incident response engagements (the data this report is drawn from).  I would like to do something there, and hope to someday, but for now we just don&#039;t have that level of information.  You could pull other data sources in that use Activity Based Cost accounting to set numbers around cost-per-record, but even then you&#039;ll likely want to use probabilistic methods to establish an acceptable range for use in risk analysis rather than a static, precise number.

Hope you&#039;re well.  Haven&#039;t had a chance to play much tennis so far this year.</description>
		<content:encoded><![CDATA[<p>Hey Patrick!</p>
<p>&#8220;If you are not a financial services company, then the question for me becomes “Why not play the odds?” Per your report, only 5% of records breached occurred at non-financial sector companies.&#8221;</p>
<p>C&#8217;mon now, after all the time we&#8217;ve spent together I know you know better.  That number isn&#8217;t number of breaches, it is number of records &#8211; and the risk tolerance of an organization isn&#8217;t set on just number of records (although record number is one informative prior in my mind) it&#8217;s every bucket of probable losses (back to FAIR training).  That said, further analysis might warrant &#8220;playing the odds&#8221; (though I&#8217;m guessing fines/judgments might convince you otherwise).</p>
<p>&#8220;And, there are so many other useful correlations that you could present (Alex, are you listening?&#8221;</p>
<p>I assure you I&#8217;m listening.  And I agree that there should be more fun to follow.  But we have multiple factors to weigh here, not the least of which is releasing a report that is digestible in length.  Nobody wants a TLDNR tome of arcane statistical analysis, but the depth of the initial (there I said it, initial) analysis had to be established at some level &#8211; we chose the one you see in the report.  My goal is to develop subsequent analysis that goes deeper where we can find useful information (see my upcoming post on Timespan of Breach Events as an example).</p>
<p>That said we can&#8217;t make some numbers appear out of thin air (nor would you want us to).  &#8220;The most important, and certainly the most difficult metric, would be, what’s the impact ($$$) of a given attack?&#8221;  Impact measurements, for example, are not in scope for Incident response engagements (the data this report is drawn from).  I would like to do something there, and hope to someday, but for now we just don&#8217;t have that level of information.  You could pull other data sources in that use Activity Based Cost accounting to set numbers around cost-per-record, but even then you&#8217;ll likely want to use probabilistic methods to establish an acceptable range for use in risk analysis rather than a static, precise number.</p>
<p>Hope you&#8217;re well.  Haven&#8217;t had a chance to play much tennis so far this year.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Florer</title>
		<link>http://securityblog.verizonbusiness.com/2009/04/14/2009-dbir-conclusions-and-recommendations/comment-page-1/#comment-289</link>
		<dc:creator>Patrick Florer</dc:creator>
		<pubDate>Fri, 17 Apr 2009 14:26:43 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=190#comment-289</guid>
		<description>All of these recommendations are reasonable and prudent, but are they really supported by your data?

If you are a financial services company, it may be that nothing is going to help you much at all, except for a complete overhaul of the international payments and credit card systems.

Given the number of targeted and highly difficult attacks you have reported against these entities, and given the fact that no upper bound on the motivaton, skill, and resources of the bad guys has been or can be established, it seems to me that the best one can hope for is to make things a bit more difficult for an attacker than at one&#039;s competitors (low hanging fruit argument).

If you are not a financial services company, then the question for me becomes &quot;Why not play the odds?&quot;  Per your report, only 5% of records breached occurred at non-financial sector companies.

So why spend all of the money on expensive security stuff, which, in the final analysis may not and probably will not protect you?

Do you suppose that non-tech executives understand this, and that&#039;s the real reason why PCI compliance is as low as you report?

In general, the 2009 report is, in my view, much more useful than the 2008 report, but it still suffers a bit from reporting what you have vs reporting what people might really like to know.  And, there are so many other useful correlations that you could present (Alex, are you listening?)

The most important, and certainly the most difficult metric, would be, what&#039;s the impact ($$$) of a given attack?  And what&#039;s the correlation between things that are known, like industry segment, attack vector, attack difficulty, number of records, etc. and that impact.

It also appears to me that there must be at least one or two huge financial services breaches that are overwhelming everything else in this data set - I know that you cannot name names, but I have a pretty good idea who it might be.  It would be nice to see some numbers that have these outliers removed - such an analysis might have more relevance to the average company out there.

Best regards,

Patrick Florer
Dallas, Texas




In general, the 2009 report is, in my view, much more useful than the 2008 report, but it still suffers a bit from reporting what you have vs reporting what people might really like to know.

The most important, and certainly the most difficult metric, would be, what&#039;s the impact of a given attack?  And what&#039;s the correlation between things that are known, like industry segment, attack vector, attack difficulty, number of records, etc. and that impact.

It also appears to me that there must be at least one huge financial services breach that is overwhelming everything else in this data set -</description>
		<content:encoded><![CDATA[<p>All of these recommendations are reasonable and prudent, but are they really supported by your data?</p>
<p>If you are a financial services company, it may be that nothing is going to help you much at all, except for a complete overhaul of the international payments and credit card systems.</p>
<p>Given the number of targeted and highly difficult attacks you have reported against these entities, and given the fact that no upper bound on the motivaton, skill, and resources of the bad guys has been or can be established, it seems to me that the best one can hope for is to make things a bit more difficult for an attacker than at one&#8217;s competitors (low hanging fruit argument).</p>
<p>If you are not a financial services company, then the question for me becomes &#8220;Why not play the odds?&#8221;  Per your report, only 5% of records breached occurred at non-financial sector companies.</p>
<p>So why spend all of the money on expensive security stuff, which, in the final analysis may not and probably will not protect you?</p>
<p>Do you suppose that non-tech executives understand this, and that&#8217;s the real reason why PCI compliance is as low as you report?</p>
<p>In general, the 2009 report is, in my view, much more useful than the 2008 report, but it still suffers a bit from reporting what you have vs reporting what people might really like to know.  And, there are so many other useful correlations that you could present (Alex, are you listening?)</p>
<p>The most important, and certainly the most difficult metric, would be, what&#8217;s the impact ($$$) of a given attack?  And what&#8217;s the correlation between things that are known, like industry segment, attack vector, attack difficulty, number of records, etc. and that impact.</p>
<p>It also appears to me that there must be at least one or two huge financial services breaches that are overwhelming everything else in this data set &#8211; I know that you cannot name names, but I have a pretty good idea who it might be.  It would be nice to see some numbers that have these outliers removed &#8211; such an analysis might have more relevance to the average company out there.</p>
<p>Best regards,</p>
<p>Patrick Florer<br />
Dallas, Texas</p>
<p>In general, the 2009 report is, in my view, much more useful than the 2008 report, but it still suffers a bit from reporting what you have vs reporting what people might really like to know.</p>
<p>The most important, and certainly the most difficult metric, would be, what&#8217;s the impact of a given attack?  And what&#8217;s the correlation between things that are known, like industry segment, attack vector, attack difficulty, number of records, etc. and that impact.</p>
<p>It also appears to me that there must be at least one huge financial services breach that is overwhelming everything else in this data set -</p>
]]></content:encoded>
	</item>
</channel>
</rss>
