<?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"
	>
<channel>
	<title>Comments for Verizon Business Security Blog</title>
	<atom:link href="http://securityblog.verizonbusiness.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://securityblog.verizonbusiness.com</link>
	<description>Risk Intelligence from Verizon Business Security Solutions powered by Cybertrust</description>
	<pubDate>Wed, 03 Dec 2008 21:17:45 +0000</pubDate>
	<generator>http://wordpress.org/?v=</generator>
		<item>
		<title>Comment on 2008 Data Breach Investigations Supplemental Report by Verizon Business Security Blog &#187; Blog Archive &#187; “Never attribute to malice that which can adequately be explained by Stupidity.”</title>
		<link>http://securityblog.verizonbusiness.com/2008/10/02/2008-data-breach-investigations-supplemental-report/#comment-54</link>
		<dc:creator>Verizon Business Security Blog &#187; Blog Archive &#187; “Never attribute to malice that which can adequately be explained by Stupidity.”</dc:creator>
		<pubDate>Wed, 15 Oct 2008 20:34:22 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=144#comment-54</guid>
		<description>[...] colleague at Verizon Business wanted to inform his customers and colleagues that we had published a supplement to our Data Breach Investigations Report. He crafted an e-mail message and used a list of addresses [...]</description>
		<content:encoded><![CDATA[<p>[...] colleague at Verizon Business wanted to inform his customers and colleagues that we had published a supplement to our Data Breach Investigations Report. He crafted an e-mail message and used a list of addresses [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on 2008 Data Breach Investigations Supplemental Report by Verizon Business Security Blog &#187; Blog Archive &#187; Peter Tippett on the Data Breach Investigations Supplemental Report</title>
		<link>http://securityblog.verizonbusiness.com/2008/10/02/2008-data-breach-investigations-supplemental-report/#comment-50</link>
		<dc:creator>Verizon Business Security Blog &#187; Blog Archive &#187; Peter Tippett on the Data Breach Investigations Supplemental Report</dc:creator>
		<pubDate>Wed, 08 Oct 2008 19:39:44 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=144#comment-50</guid>
		<description>[...] Terms of Use      &#171; 2008 Data Breach Investigations Supplemental Report [...]</description>
		<content:encoded><![CDATA[<p>[...] Terms of Use      &laquo; 2008 Data Breach Investigations Supplemental Report [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on 2008 Data Breach Investigations Report by Russ Cooper</title>
		<link>http://securityblog.verizonbusiness.com/2008/06/10/2008-data-breach-investigations-report/#comment-31</link>
		<dc:creator>Russ Cooper</dc:creator>
		<pubDate>Thu, 07 Aug 2008 16:37:19 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=80#comment-31</guid>
		<description>Kyle,

Given that there are absolutely no known's in "unknown unknown", speculating that anything represents the majority of those cases is, well, wild speculation. Honestly, its as likely to be use of graphic card memory for tools or violation of VM boundaries. It could be anything.

Also, from a risk calculation perspective, the simple cost of purchasing drives, let alone drives from Nigeria, would make this an unlikely option for criminals. It’s far easier to compromise a system electronically via no-cost bots across no-cost network links than to purchase anything from anywhere.

Regardless whether you agree that IT disposal represents the "biggest hidden risk," it does represent a risk that should be considered. Local disposal (or loss via 3rd parties) of unencrypted data tapes has been widely reported on, regardless whether that lost data was ever used in a crime. The reputation losses that can incur as a result should make businesses aware there is real risk involved.

That all said, it has been repeatedly demonstrated that a concerted effort can reassemble data from even the most damaged drives (the Space Shuttle drive data reconstruction being but one example), so if data is going to be left unencrypted on any physical device the furnace becomes your only safe bet.

Applying data sensitivity identification can mitigate some risk. If your data is valuable for, at most, 6 months then simply keep the old drives that long before disposing of them. If the data has value for a longer period, adjust accordingly. If the storage time becomes too long, or the risk of using 3rd parties for such storage, then encryption becomes a cheaper option (despite it costing more than not using it, providing its cheaper than storing the data.) If, however, your data is sensitive for a period that makes brute force decryption viable, then we're back to the furnace.

Personally, I would be more concerned about the entity who accepts the drives directly from me, than from whomever they ship those drives to. That first party has knowledge of who I am and which drives are mine, and therefore are in the position to pick and choose drives that might be valuable. Whoever is receiving these drives in, for example, Nigeria has far less knowledge and ends up having to go through a far greater volume of noise to get to a signal. That alone reduces the likelihood, and therefore the risk.

We have long recommended that sensitive data should be encrypted at rest. If it is, then it is likely to be encrypted in transit (e.g. via Internet backup or physical tape transfers.) This mitigates many issues brought up in the media, and should satisfy most regulatory requirements. Keeping data encrypted in memory (or while in use by an application) can be desirable and may reduce some specific risks, but has far less overall risk reducing benefits than encrypting at rest.

None of this is meant to suggest that the outsourcing of IT disposal shouldn't involve investigating how that entity handles the data/devices, or, that there aren't differences between providers of such services. All outsourcing should involve investigation of all pertinent details.

Thanks for pointing this out, Kyle.

Cheers,
Russ</description>
		<content:encoded><![CDATA[<p>Kyle,</p>
<p>Given that there are absolutely no known&#8217;s in &#8220;unknown unknown&#8221;, speculating that anything represents the majority of those cases is, well, wild speculation. Honestly, its as likely to be use of graphic card memory for tools or violation of VM boundaries. It could be anything.</p>
<p>Also, from a risk calculation perspective, the simple cost of purchasing drives, let alone drives from Nigeria, would make this an unlikely option for criminals. It’s far easier to compromise a system electronically via no-cost bots across no-cost network links than to purchase anything from anywhere.</p>
<p>Regardless whether you agree that IT disposal represents the &#8220;biggest hidden risk,&#8221; it does represent a risk that should be considered. Local disposal (or loss via 3rd parties) of unencrypted data tapes has been widely reported on, regardless whether that lost data was ever used in a crime. The reputation losses that can incur as a result should make businesses aware there is real risk involved.</p>
<p>That all said, it has been repeatedly demonstrated that a concerted effort can reassemble data from even the most damaged drives (the Space Shuttle drive data reconstruction being but one example), so if data is going to be left unencrypted on any physical device the furnace becomes your only safe bet.</p>
<p>Applying data sensitivity identification can mitigate some risk. If your data is valuable for, at most, 6 months then simply keep the old drives that long before disposing of them. If the data has value for a longer period, adjust accordingly. If the storage time becomes too long, or the risk of using 3rd parties for such storage, then encryption becomes a cheaper option (despite it costing more than not using it, providing its cheaper than storing the data.) If, however, your data is sensitive for a period that makes brute force decryption viable, then we&#8217;re back to the furnace.</p>
<p>Personally, I would be more concerned about the entity who accepts the drives directly from me, than from whomever they ship those drives to. That first party has knowledge of who I am and which drives are mine, and therefore are in the position to pick and choose drives that might be valuable. Whoever is receiving these drives in, for example, Nigeria has far less knowledge and ends up having to go through a far greater volume of noise to get to a signal. That alone reduces the likelihood, and therefore the risk.</p>
<p>We have long recommended that sensitive data should be encrypted at rest. If it is, then it is likely to be encrypted in transit (e.g. via Internet backup or physical tape transfers.) This mitigates many issues brought up in the media, and should satisfy most regulatory requirements. Keeping data encrypted in memory (or while in use by an application) can be desirable and may reduce some specific risks, but has far less overall risk reducing benefits than encrypting at rest.</p>
<p>None of this is meant to suggest that the outsourcing of IT disposal shouldn&#8217;t involve investigating how that entity handles the data/devices, or, that there aren&#8217;t differences between providers of such services. All outsourcing should involve investigation of all pertinent details.</p>
<p>Thanks for pointing this out, Kyle.</p>
<p>Cheers,<br />
Russ</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on 2008 Data Breach Investigations Report by Retire-IT</title>
		<link>http://securityblog.verizonbusiness.com/2008/06/10/2008-data-breach-investigations-report/#comment-30</link>
		<dc:creator>Retire-IT</dc:creator>
		<pubDate>Tue, 05 Aug 2008 20:28:59 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=80#comment-30</guid>
		<description>The biggest hidden risk of data security involves IT disposal. Often companies rely on electronics recyclers to protect them by destroying data on retired hard drives. 

Sadly, 80% of unwanted US computer equipment is exported to developing countries by these so-called recyclers - often with confidential data still on hard drives.  

As the Verizon study states “criminals prefer to exploit weaknesses rather than strengths.” What could be easier than buying old hard drives from an e-scrap dealer in Nigeria? 

Outsourcing IT disposal makes sense. But if an organization fails to maintain proper oversight, outsourcing actually increases the risks, provides a false sense of security, and is likely the majority of the 90% of breaches that involve some type of "unknown unknown."

Kyle Marks
President &#38; CEO
Retire-IT, LLC
kmarks@retire-it.com</description>
		<content:encoded><![CDATA[<p>The biggest hidden risk of data security involves IT disposal. Often companies rely on electronics recyclers to protect them by destroying data on retired hard drives. </p>
<p>Sadly, 80% of unwanted US computer equipment is exported to developing countries by these so-called recyclers - often with confidential data still on hard drives.  </p>
<p>As the Verizon study states “criminals prefer to exploit weaknesses rather than strengths.” What could be easier than buying old hard drives from an e-scrap dealer in Nigeria? </p>
<p>Outsourcing IT disposal makes sense. But if an organization fails to maintain proper oversight, outsourcing actually increases the risks, provides a false sense of security, and is likely the majority of the 90% of breaches that involve some type of &#8220;unknown unknown.&#8221;</p>
<p>Kyle Marks<br />
President &amp; CEO<br />
Retire-IT, LLC<br />
<a href="mailto:kmarks@retire-it.com">kmarks@retire-it.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on DNS Facts and Scenarios by df</title>
		<link>http://securityblog.verizonbusiness.com/2008/07/25/dns-exploits-what-could-actually-happen/#comment-25</link>
		<dc:creator>df</dc:creator>
		<pubDate>Fri, 25 Jul 2008 20:47:23 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=131#comment-25</guid>
		<description>"First, we are unaware of any evidence of any new attacks in this realm. DNS cache poisoning is a very old attack technique. So far there is discussion and angst, but no new attack activity."

Are you not counting that the attack was made available as a module for Metasploit about 36 hours before this was posted? Also, the fact that the technique of DNS cache poisoning is very old is irrelevant. Almost all (if not all) new exploits are applications of very old techiniques.


"Q: But couldn’t the criminal attack and “own” the user’s browser?
A: Only if that browser was vulnerable anyway. "

Or you are running JavaScript, which almost every browser is. Even if you are using FireFox with NoScript, if it is a trusted site, you likely will have allowed the site to execute JS in your browser. See Jeremiah's Black Hat presentations from 2005 and 2006.
		http://www.blackhat.com/presentations/bh-jp-05/bh-jp-05-grossman.pdf
		http://jeremiahgrossman.blogspot.com/2006/08/home-from-blackhat-and-defcon.html


"But even if all of these things fail, the criminal still only has ownership of PCs in your company which have visited the same site."

But once the criminal has control over 1 computer, he can cause that computer to initiate requests for any domain he wishes, launching his UDP flood at the same time, and thereby poisoning even more domains for that company. Not to mention he then has some degree of access behind your firewall and can begin probing your internal network; and that is still with nothing more than JS.


"Q: Couldn’t the criminal snooker the user into typing in personally identifying information to be exploited later?
A: Only if that user would have done so anyway. If the new site has a certificate, it will fail and the user will get certificate errors in the browser."

Why wouldn't the user type their login information into their bank's website? As far as the certificate is concerned, a couple of other options here. The more likely is that "Mallory" will get a valid cert on a look-a-like domain and the user isn't likely to notice the difference. More evil, but substantially less likely, if a cert vendor has their DNS cache poisoned then Mallory could get a cert with the real domain name issued for his site. Many cert vendors will issue a basic cert with little more than an uploaded CSR and a matching file on the server. The criminal doesn't have to redirect to the bank, thereby revealing a single IP; the criminal could just put up a "service unavailable" notice after login.


"The ISP hosting the poisoned DNS would probably get support calls from customers unable to get to their search engine"

Because all of those people using free WiFi at coffee shops know who to call for support? What are they going to do? Tell the barista they can't get to a specific web site? The barista has more important things to worry about, like was that a half-foam, no-fat or a no-foam, half-fat latte?


"Q: Couldn’t criminals perform man-in-the-middle (MITM) attacks?
A: Sure, but consider the volume and the processing power they’d require."

It would not require much processing power at all to copy all emails sent to a domain and then forward the message on to the intended mail server.</description>
		<content:encoded><![CDATA[<p>&#8220;First, we are unaware of any evidence of any new attacks in this realm. DNS cache poisoning is a very old attack technique. So far there is discussion and angst, but no new attack activity.&#8221;</p>
<p>Are you not counting that the attack was made available as a module for Metasploit about 36 hours before this was posted? Also, the fact that the technique of DNS cache poisoning is very old is irrelevant. Almost all (if not all) new exploits are applications of very old techiniques.</p>
<p>&#8220;Q: But couldn’t the criminal attack and “own” the user’s browser?<br />
A: Only if that browser was vulnerable anyway. &#8221;</p>
<p>Or you are running JavaScript, which almost every browser is. Even if you are using FireFox with NoScript, if it is a trusted site, you likely will have allowed the site to execute JS in your browser. See Jeremiah&#8217;s Black Hat presentations from 2005 and 2006.<br />
		<a href="http://www.blackhat.com/presentations/bh-jp-05/bh-jp-05-grossman.pdf" rel="nofollow">http://www.blackhat.com/presentations/bh-jp-05/bh-jp-05-grossman.pdf</a><br />
		<a href="http://jeremiahgrossman.blogspot.com/2006/08/home-from-blackhat-and-defcon.html" rel="nofollow">http://jeremiahgrossman.blogspot.com/2006/08/home-from-blackhat-and-defcon.html</a></p>
<p>&#8220;But even if all of these things fail, the criminal still only has ownership of PCs in your company which have visited the same site.&#8221;</p>
<p>But once the criminal has control over 1 computer, he can cause that computer to initiate requests for any domain he wishes, launching his UDP flood at the same time, and thereby poisoning even more domains for that company. Not to mention he then has some degree of access behind your firewall and can begin probing your internal network; and that is still with nothing more than JS.</p>
<p>&#8220;Q: Couldn’t the criminal snooker the user into typing in personally identifying information to be exploited later?<br />
A: Only if that user would have done so anyway. If the new site has a certificate, it will fail and the user will get certificate errors in the browser.&#8221;</p>
<p>Why wouldn&#8217;t the user type their login information into their bank&#8217;s website? As far as the certificate is concerned, a couple of other options here. The more likely is that &#8220;Mallory&#8221; will get a valid cert on a look-a-like domain and the user isn&#8217;t likely to notice the difference. More evil, but substantially less likely, if a cert vendor has their DNS cache poisoned then Mallory could get a cert with the real domain name issued for his site. Many cert vendors will issue a basic cert with little more than an uploaded CSR and a matching file on the server. The criminal doesn&#8217;t have to redirect to the bank, thereby revealing a single IP; the criminal could just put up a &#8220;service unavailable&#8221; notice after login.</p>
<p>&#8220;The ISP hosting the poisoned DNS would probably get support calls from customers unable to get to their search engine&#8221;</p>
<p>Because all of those people using free WiFi at coffee shops know who to call for support? What are they going to do? Tell the barista they can&#8217;t get to a specific web site? The barista has more important things to worry about, like was that a half-foam, no-fat or a no-foam, half-fat latte?</p>
<p>&#8220;Q: Couldn’t criminals perform man-in-the-middle (MITM) attacks?<br />
A: Sure, but consider the volume and the processing power they’d require.&#8221;</p>
<p>It would not require much processing power at all to copy all emails sent to a domain and then forward the message on to the intended mail server.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Insider Breach Stats: Bogus, Biased, or Believable? by Russ Cooper</title>
		<link>http://securityblog.verizonbusiness.com/2008/07/07/bogus-biased-or-believable/#comment-23</link>
		<dc:creator>Russ Cooper</dc:creator>
		<pubDate>Mon, 21 Jul 2008 14:49:37 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=126#comment-23</guid>
		<description>@Hawke: You bring up an interesting point and, to a certain extent, we agree - managing risk is clearly the right focus. We do not, however, think the number of breaches is the “wrong” statistic. Since risk is the product of likelihood (number of incidents) and impact, statistics on both parameters are necessary. Concentrating solely on impact or damage quickly leads to a form of decision making we like to call “WIBiHI” (Wouldn’t It Be Horrible If…”) and can often result in gross overspending. As you suggest, managing security based on likelihood, alone, isn’t a winning strategy either.

Keep in mind the original blog post is in response to public reaction to our findings regarding the percentage of breaches involving insiders. We’re not suggesting likelihood is more important than impact (or damage); it’s just that nobody seemed to argue against or misconstrue the latter parameter.</description>
		<content:encoded><![CDATA[<p>@Hawke: You bring up an interesting point and, to a certain extent, we agree - managing risk is clearly the right focus. We do not, however, think the number of breaches is the “wrong” statistic. Since risk is the product of likelihood (number of incidents) and impact, statistics on both parameters are necessary. Concentrating solely on impact or damage quickly leads to a form of decision making we like to call “WIBiHI” (Wouldn’t It Be Horrible If…”) and can often result in gross overspending. As you suggest, managing security based on likelihood, alone, isn’t a winning strategy either.</p>
<p>Keep in mind the original blog post is in response to public reaction to our findings regarding the percentage of breaches involving insiders. We’re not suggesting likelihood is more important than impact (or damage); it’s just that nobody seemed to argue against or misconstrue the latter parameter.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on DNS Vulnerability Is Important, but There&#8217;s No Reason to Panic by Dan Kaminsky</title>
		<link>http://securityblog.verizonbusiness.com/2008/07/15/dns-vulnerability-is-important-but-theres-no-reason-to-panic/#comment-22</link>
		<dc:creator>Dan Kaminsky</dc:creator>
		<pubDate>Sat, 19 Jul 2008 19:24:19 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=129#comment-22</guid>
		<description>As the original finder of this issue, I'd just like to express my support for the core message of this post.  The vulnerability is important, and should be fixed by August 6th, but there is no reason to panic,  and every reason to test your updated deployments.  Screw up DNS, and all goes wobbly very very fast.</description>
		<content:encoded><![CDATA[<p>As the original finder of this issue, I&#8217;d just like to express my support for the core message of this post.  The vulnerability is important, and should be fixed by August 6th, but there is no reason to panic,  and every reason to test your updated deployments.  Screw up DNS, and all goes wobbly very very fast.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Patch Management - Speed Is of the Essence by Dominic White's .tHE pRODUCT</title>
		<link>http://securityblog.verizonbusiness.com/2008/07/01/123/#comment-21</link>
		<dc:creator>Dominic White's .tHE pRODUCT</dc:creator>
		<pubDate>Sat, 19 Jul 2008 12:29:48 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=123#comment-21</guid>
		<description>&lt;strong&gt;Vulnerability Life Cycle...&lt;/strong&gt;


Schneier once proposed a vulnerability life cycle in a Crypto-Gram newsletter. However, during the time of writing my thesis, there were several important pieces of research no-one had put together to come up with a 'more correct' vulnerability lif...</description>
		<content:encoded><![CDATA[<p><strong>Vulnerability Life Cycle&#8230;</strong></p>
<p>Schneier once proposed a vulnerability life cycle in a Crypto-Gram newsletter. However, during the time of writing my thesis, there were several important pieces of research no-one had put together to come up with a &#8216;more correct&#8217; vulnerability lif&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Insider Breach Stats: Bogus, Biased, or Believable? by Hawke</title>
		<link>http://securityblog.verizonbusiness.com/2008/07/07/bogus-biased-or-believable/#comment-19</link>
		<dc:creator>Hawke</dc:creator>
		<pubDate>Fri, 11 Jul 2008 15:45:28 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=126#comment-19</guid>
		<description>Is number of breaches indider vs. outsider relevant, or are we looking at the wrong statistic.

If I'm managing risk instead of metrics, I want to know the amount of damage (exposure) done by one or the other. The data clearly shows that the insiders _do the most damage_ to an organization in terms of data exposure.

My experience is that it is also more costly to clean up after an insider.</description>
		<content:encoded><![CDATA[<p>Is number of breaches indider vs. outsider relevant, or are we looking at the wrong statistic.</p>
<p>If I&#8217;m managing risk instead of metrics, I want to know the amount of damage (exposure) done by one or the other. The data clearly shows that the insiders _do the most damage_ to an organization in terms of data exposure.</p>
<p>My experience is that it is also more costly to clean up after an insider.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What Do We Mean by “Reasonable Controls?” by Russ Cooper</title>
		<link>http://securityblog.verizonbusiness.com/2008/06/19/reasonable-controls/#comment-17</link>
		<dc:creator>Russ Cooper</dc:creator>
		<pubDate>Wed, 25 Jun 2008 20:26:35 +0000</pubDate>
		<guid isPermaLink="false">http://securityblog.verizonbusiness.com/?p=117#comment-17</guid>
		<description>Ben, we think that your use of the word "conventional" could be seen to be just as subjective as our use of "reasonable controls." It may very well carry a different meaning for you, the reader, and us.  We don't necessarily think conventional opinion is irrational.  Error was a factor in 62% of our caseload. We think the majority had defined a policy, based on conventional thinking, but they simply hadn't implemented it, or implemented it contrary to their own policy.
 
As you say, Ben, "The cost of locking down data includes much more than merely correcting particular mistakes." We don't disagree.  However, our data shows that eliminating error significantly reduces risk.  We believe in many cases one single defensive action can significantly reduce risk, and there are certainly instances where a handful of simple, inexpensive controls can reduce almost all significant risks.  There is a point at which implementing more does not achieve equivalent, or even significant, risk reduction. One cannot argue that doing what you have defined in your own policy is a "bad thing," only, possibly, that your policy need not be as elaborate as you may have it.
 
I'm sure we agree there are operational costs for any network, and I think we agree those costs include "vigilance, equipment upgrades, employee training, auditing, etc.  They may also possibly include "policing of business partners,” and definitely de-provisioning of network connections, etc. I'd hope you'd also agree characterizing them as purely security costs is too narrow in the extreme, versus reasonable network operational costs.  Whoops, there goes that word "reasonable" again! 
 
We're also not suggesting that myriad attack paths be "locked down."  Our risk-based approach considers paths of least resistance and greatest availability (i.e., areas of greatest risk).  Our study data shows opportunistic attacks of low skill level can be extremely successful.  Such attacks remain successful because the cost of attack is relatively low for the criminal.  We believe in implementing controls to the point an organization is no longer a target of opportunity (they become a target of choice). This doesn't mean the organization has plugged every hole, but it does mean they have made the cost of attack for the criminal higher than for other potential targets.
 
As you suggest, it is conceivable that the cost of attack could be increased by factors other than the implementation of internal controls. There may well be value, for instance, in making data less desirable or valuable to the criminal. Unfortunately, most organizations simply do not have the capacity to accomplish this, much less influence external changes on a scale comparable to the suggested revamp of the credit card system. It's hard to argue against such ideas. In the meantime, however, there remains a need for organizations to implement effective and efficient measures of securing the environment over which they have control.</description>
		<content:encoded><![CDATA[<p>Ben, we think that your use of the word &#8220;conventional&#8221; could be seen to be just as subjective as our use of &#8220;reasonable controls.&#8221; It may very well carry a different meaning for you, the reader, and us.  We don&#8217;t necessarily think conventional opinion is irrational.  Error was a factor in 62% of our caseload. We think the majority had defined a policy, based on conventional thinking, but they simply hadn&#8217;t implemented it, or implemented it contrary to their own policy.</p>
<p>As you say, Ben, &#8220;The cost of locking down data includes much more than merely correcting particular mistakes.&#8221; We don&#8217;t disagree.  However, our data shows that eliminating error significantly reduces risk.  We believe in many cases one single defensive action can significantly reduce risk, and there are certainly instances where a handful of simple, inexpensive controls can reduce almost all significant risks.  There is a point at which implementing more does not achieve equivalent, or even significant, risk reduction. One cannot argue that doing what you have defined in your own policy is a &#8220;bad thing,&#8221; only, possibly, that your policy need not be as elaborate as you may have it.</p>
<p>I&#8217;m sure we agree there are operational costs for any network, and I think we agree those costs include &#8220;vigilance, equipment upgrades, employee training, auditing, etc.  They may also possibly include &#8220;policing of business partners,” and definitely de-provisioning of network connections, etc. I&#8217;d hope you&#8217;d also agree characterizing them as purely security costs is too narrow in the extreme, versus reasonable network operational costs.  Whoops, there goes that word &#8220;reasonable&#8221; again! </p>
<p>We&#8217;re also not suggesting that myriad attack paths be &#8220;locked down.&#8221;  Our risk-based approach considers paths of least resistance and greatest availability (i.e., areas of greatest risk).  Our study data shows opportunistic attacks of low skill level can be extremely successful.  Such attacks remain successful because the cost of attack is relatively low for the criminal.  We believe in implementing controls to the point an organization is no longer a target of opportunity (they become a target of choice). This doesn&#8217;t mean the organization has plugged every hole, but it does mean they have made the cost of attack for the criminal higher than for other potential targets.</p>
<p>As you suggest, it is conceivable that the cost of attack could be increased by factors other than the implementation of internal controls. There may well be value, for instance, in making data less desirable or valuable to the criminal. Unfortunately, most organizations simply do not have the capacity to accomplish this, much less influence external changes on a scale comparable to the suggested revamp of the credit card system. It&#8217;s hard to argue against such ideas. In the meantime, however, there remains a need for organizations to implement effective and efficient measures of securing the environment over which they have control.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
