<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title><![CDATA[[SecurityRatty] tag: describe]]></title>
    <link>http://securityratty.com/tag/describe</link>
    <description></description>
    <pubDate>Tue, 07 Oct 2008 01:48:53 +0000</pubDate>
    <generator>iRatty Engine</generator>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <item>
      <title><![CDATA[Rational Risk Management, Angry Italians, and Irrational Security Analysts]]></title>
      <link>http://securityratty.com/article/616867e9cd4e8203d8c23c0bef989749</link>
      <guid>http://securityratty.com/article/616867e9cd4e8203d8c23c0bef989749</guid>
      <description><![CDATA[Hope you all had a great weekend. I had meant to point you earlier to a FAIR analysis that Chris Hayes did over at his Blog . But Ive been a little busy, and before I could mention it, Stuart King put...]]></description>
      <content:encoded><![CDATA[<p>Hope you all had a great weekend.  I had meant to point you earlier to a <strong><a href="http://risktical.com/2008/11/06/security-template-exception-part-2-%E2%80%93-the-assessment/">FAIR analysis that Chris Hayes did over at his Blog</a></strong>.  But I&#8217;ve been a little busy, and before I could mention it, Stuart King <strong><a href="http://www.computerweekly.com/blogs/stuart_king/2008/11/ive-written-up-a-report.html">put up a kind of angry response</a></strong> on his ComputerWorld blog.  Snark aside, there are a couple of other really troubling aspects of Stuart&#8217;s reaction to Chris&#8217; analysis that I thought we could talk about this morning.</p>
<blockquote><p>The problem is that (Chris&#8217; analysis is) completely impractical. I&#8217;ll take a recent, and fairly typical situation as an example. I was taking issue with the manner in which remote access was being provisioned for a third party vendor to connect to a system hosted by one of our European business units. To cut a long story short, it was not only a breach of policy but highly insecure. I wanted the access to be disconnected, the business unit director wanted my risk assessment. And he didn&#8217;t want to wait for it.</p>
<p>To quote Chris Hayes, spending time on working out <em> <strong>the expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force </strong></em>was not going to pacify an angry Italian fearful that my decision was going to cost him money. He wanted my explanation of the risk and more importantly, what I was going to offer as a solution to keep his business functioning</p></blockquote>
<p>As Chris is someone who actually does this for a living in a large company, and this is typical of his actual day job, I really find Stuart&#8217;s &#8220;impractical&#8221; comment to be, um, misinformed.</p>
<p>Also, I think Stuart mistakes the purpose of a risk analysis.  The purpose of the risk analysis is not to force someone to be &#8220;secure&#8221;, but to provide knowledge for decision making.  Using it as a &#8220;hammer&#8221; to knock in the nail of your personal risk tolerance impairs efficiency and in the long run retards &#8220;security&#8221; as it creates political resentment.  Seriously, who cares if something might violate policy or not in a pre-implementation discussion?  Policies are not stone tablets handed down from on high, they are state-in-time codification of the <em><strong>data owners </strong></em>risk tolerance.  This risk tolerance changes sometimes, and that&#8217;s OK.</p>
<p>To that extent, I appreciate (and I&#8217;m sure Chris does, as well) that risk analysis does not create rationality in the data owner.  Someone who sees you as a speedbump on the route to progress they may not be ready to appreciate your point of view even if it is stated in the most rational manner possible.   But it&#8217;s worth noting (and Stuart&#8217;s example is indicative of this point) that <em><strong>risk analysis does not create rationality in the analyst, either</strong></em>.  If one is being so &#8220;security minded&#8221; as to ignore the risk tolerance of the business owner - we&#8217;re bound to get a reaction similar to that Stuart encountered.  In fact, a practical risk analysis like Chris performed on his blog, done in 30 minutes, should identify the critical point of disagreement between Stuart and the data owner (again, Stuart doesn&#8217;t own the data, the agitated Italian does).</p>
<p>But let&#8217;s stay rational and open to alternatives to what Chris offers.  Stuart states his approach to risk analysis as:</p>
<blockquote><p>When I need to document a risk assessment I use a very simple form: list the threats, state the level of vulnerability, list the associated operational costs and potential revenue hits. High, medium, or low risk? Describe the controls and options. Write up who needs to do what, and how much of their time it&#8217;s going to take. Job done.</p></blockquote>
<p>At first glance, I don&#8217;t think what Chris has done is any less efficient, and it provides greater insight (using Frequency and Capability instead of just &#8216;listing the threats&#8217;).  But what is key here is that Chris&#8217; approach is consistent and defensible.  Less generous risk geeks and CSO&#8217;s I know would have no little difficulty with Stuart&#8217;s approach.  But to particularly answer Stuart&#8217;s main objection (impracticality) I would offer that with practice, Chris&#8217; work is probably quicker and easier than Stuart&#8217;s described process as it eliminates much of the ambiguity an immature risk analysis creates - reducing the need for further discussion and arguments with data owners (regardless of disposition or nationality).</p>
<p>Finally the irony of Stuart&#8217;s post is that the reason he had this confrontation may in fact be because he was incapable of bringing a salient model for risk to the table, one that identified the factors that create risk and developed a defensible belief statement concerning risk.   We&#8217;ll never know if one would have helped him in this isolated instance, but I can tell you that in organizations like Chris&#8217;, good risk models and strong risk anlayses create operational efficiencies, reduce costs, and streamlines intra-departmental communications.</p>
]]></content:encoded>
      <pubDate>Mon, 17 Nov 2008 13:43:15 +0000</pubDate>
      <category domain="http://securityratty.com/tag/risk">risk</category>
      <category domain="http://securityratty.com/tag/risk tolerance">risk tolerance</category>
      <category domain="http://securityratty.com/tag/risk models">risk models</category>
      <category domain="http://securityratty.com/tag/practical risk analysis">practical risk analysis</category>
      <category domain="http://securityratty.com/tag/strong risk anlayses">strong risk anlayses</category>
      <category domain="http://securityratty.com/tag/generous risk geeks">generous risk geeks</category>
      <category domain="http://securityratty.com/tag/immature risk analysis">immature risk analysis</category>
      <category domain="http://securityratty.com/tag/quote chris hayes">quote chris hayes</category>
      <category domain="http://securityratty.com/tag/chris hayes">chris hayes</category>
      <source url="http://riskmanagementinsight.com/riskanalysis/?p=520">Rational Risk Management, Angry Italians, and Irrational Security Analysts</source>
    </item>
    <item>
      <title><![CDATA[Credit Cards Failing Open]]></title>
      <link>http://securityratty.com/article/0d97a3eab73024d98685f3d33f481217</link>
      <guid>http://securityratty.com/article/0d97a3eab73024d98685f3d33f481217</guid>
      <description><![CDATA[Most consumers are aware that when you close a credit card account, its not really closed . For convenience reasons, recurring subscription charges such as your cable bill will continue to be...]]></description>
      <content:encoded><![CDATA[<p>Most consumers are aware that when you close a credit card account, <a href="http://news.bbc.co.uk/2/hi/programmes/moneybox/3227850.stm">it&#8217;s not really closed</a>.  For &#8220;convenience&#8221; reasons, recurring subscription charges such as your cable bill will continue to be approved.  You can kind of see where the credit card companies are coming from, but it&#8217;s a pretty weak argument.  The cable company just needs to notify me that the credit card on file is no longer valid, and I&#8217;ll update my information.  Problem solved.</p>
<p>But that credit card weirdness is nothing compared to the one I&#8217;m about to describe.  </p>
<p>Before we do that, let&#8217;s take a moment to discuss the design principle of <a href="https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/349-BSI.html">failing securely</a>.  The general idea is that if a security mechanism fails, it should fail closed.  If your firewall crashes, it should block all traffic, not allow all the packets through.  If the power source to your card key system is interrupted, it shouldn&#8217;t unlock all the doors.  If the connection between your application server and your LDAP directory is severed, subsequent authentication requests should be rejected, not approved.  This is not rocket science.</p>
<p>So back to credit cards.  I had a conversation last night with an old friend who related a bizarre situation they had encountered during the QA process for one of their web applications.  One of their tests involved repeatedly attempting a credit card transaction using a canceled/expired American Express card.  Here&#8217;s what they saw in their logs, paraphrased by me:</p>
<pre>
Attempt 1: Denied
Attempt 2: Denied
Attempt 3: Denied
 .
 .
 .
Attempt 49: Denied
Attempt 50: Denied
Attempt 51: Approved
</pre>
<p>What the&#8230;?  Approved?  That can&#8217;t be right.  So they ran the test again.  Every time, after multiple consecutive rejected attempts, the transaction would inexplicably go through.  The threshold wasn&#8217;t always 50, but the general pattern was consistent &#8212; keep trying and eventually it&#8217;ll work.  Clearly, this had to be a bug in the code, but a deep-dive into the guts of the application turned up nothing. The application security group got American Express on the phone to see if they had any insight on this odd behavior.  The answer?  They didn&#8217;t concede the failure was on their end, despite log data showing the successful authorization codes.  </p>
<p>My gut instinct would be that the application requesting the transactions wasn&#8217;t failing securely (e.g. network connection to AmEx timed out, so just approve the transaction).  But that explanation wouldn&#8217;t account for authorization codes coming back.</p>
<p>So what in the world is going on here?  Why would the system behave this way?  Is it by design?  I can&#8217;t think of a single legitimate use case for failing open like this.  If this is actually a design decision by the credit card companies, I have no doubt that someone in our audience knows the rest of the story.</p>
]]></content:encoded>
      <pubDate>Thu, 30 Oct 2008 16:35:34 +0000</pubDate>
      <category domain="http://securityratty.com/tag/credit card transaction">credit card transaction</category>
      <category domain="http://securityratty.com/tag/transaction">transaction</category>
      <category domain="http://securityratty.com/tag/credit card">credit card</category>
      <category domain="http://securityratty.com/tag/credit card companies">credit card companies</category>
      <category domain="http://securityratty.com/tag/credit card weirdness">credit card weirdness</category>
      <category domain="http://securityratty.com/tag/credit card account">credit card account</category>
      <category domain="http://securityratty.com/tag/attempt">attempt</category>
      <category domain="http://securityratty.com/tag/application server">application server</category>
      <category domain="http://securityratty.com/tag/application">application</category>
      <source url="http://www.veracode.com/blog/2008/10/credit-cards-failing-open/">Credit Cards Failing Open</source>
    </item>
    <item>
      <title><![CDATA[Quantum Cryptography]]></title>
      <link>http://securityratty.com/article/665acbc2a4e65a38fe46108c2e80bb3b</link>
      <guid>http://securityratty.com/article/665acbc2a4e65a38fe46108c2e80bb3b</guid>
      <description><![CDATA[Quantum cryptography is back in the news, and the basic idea is still unbelievably cool, in theory, and nearly useless in real life
The idea behind quantum crypto is that two people communicating...]]></description>
      <content:encoded><![CDATA[<p>Quantum cryptography is back in the news, and the basic idea is still unbelievably cool, in theory, and nearly useless in real life.</p>

<p>The idea behind quantum crypto is that two people communicating using a quantum channel can be absolutely sure no one is eavesdropping.  Heisenberg's uncertainty principle requires anyone measuring a quantum system to disturb it, and that disturbance alerts legitimate users as to the eavesdropper's presence.  No disturbance, no eavesdropper -- period.</p>

<p>This month we've seen reports on a new <a href="http://news.bbc.co.uk/2/hi/science/nature/7661311.stm">working</a> quantum-key distribution <a href="http://news.cnet.com/8301-1009_3-10064219-83.html?part=rss&subj=news&tag=2547-1_3-0-5">network</a> in Vienna, and a new quantum-key distribution <a href="http://www.theregister.co.uk/2008/10/09/quantum_crypto_turbo_charged/">technique</a> out of Britain. Great stuff, but headlines like the BBC's "'Unbreakable' encryption unveiled" are a bit much.</p>

<p>The basic science behind quantum crypto was developed, and prototypes built, in the early 1980s by Charles Bennett and Giles Brassard, and there have been <a href="http://www.cs.mcgill.ca/~crepeau/CRYPTO/Biblio-QC.html">steady advances</a> in engineering since then. I describe basically how it all works in <cite>Applied Cryptography, 2nd Edition</cite> (pages 554-557). At least one company already <a href="http://www.magiqtech.com/">sells</a> quantum-key distribution products.</p>

<p>Note that this is totally separate from <a href="http://en.wikipedia.org/wiki/Quantum_computer">quantum computing</a>, which also has implications for cryptography. Several groups are working on designing and building a quantum computer, which is fundamentally different from a classical computer. If one were built -- and we're talking science fiction here -- then it could factor numbers and solve discrete-logarithm problems very quickly. In other words, it could break all of our commonly used public-key algorithms. For symmetric cryptography it's not that dire: A quantum computer would effectively halve the key length, so that a 256-bit key would be only as secure as a 128-bit key today. Pretty serious stuff, but years away from being practical. I think the best quantum computer today can factor the number 15.</p>

<p>While I like the science of quantum cryptography -- my undergraduate degree was in physics -- I don't see any commercial value in it. I don't believe it solves any security problem that needs solving. I don't believe that it's worth paying for, and I can't imagine anyone but a few technophiles buying and deploying it. Systems that use it don't magically become unbreakable, because the quantum part doesn't address the weak points of the system.</p>

<p>Security is a chain; it's as strong as the weakest link. Mathematical cryptography, as bad as it sometimes is, is the strongest link in most security chains. Our symmetric and public-key algorithms are pretty good, even though they're not based on much rigorous mathematical theory. The real problems are elsewhere: computer security, network security, user interface and so on.</p>

<p>Cryptography is the one area of security that we can get right. We already have good encryption algorithms, good authentication algorithms and good key-agreement protocols.  Maybe quantum cryptography can make that link stronger, but why would anyone bother? There are far more serious security problems to worry about, and it makes much more sense to spend effort securing those.</p>

<p>As I've often said, it's like defending yourself against an approaching attacker by putting a huge stake in the ground. It's useless to argue about whether the stake should be 50 feet tall or 100 feet tall, because either way, the attacker is going to go around it. Even quantum cryptography doesn't "solve" all of cryptography: The keys are exchanged with photons, but a conventional mathematical algorithm takes over for the actual encryption.</p>

<p>I'm always in favor of security research, and I have enjoyed following the developments in quantum cryptography. But as a product, it has no future. It's not that quantum cryptography might be insecure; it's that cryptography is already sufficiently secure.</p>

<p>This essay <a href="http://www.wired.com/politics/security/commentary/securitymatters/2008/10/securitymatters_1016">previously appeared</a> on Wired.com.</p>

<p>EDITED TO ADD (10/21):  It's amazing; even reporters <a href="http://www.itproportal.com/articles/2008/10/20/can-quantum-computing-be-used-tackle-payment-card-fraud/">responding to my essay</a> get it completely wrong:</p>

<blockquote>Keith Harrison, a cryptographer with HP Laboratories, is quoted by the Telegraph as saying that, as quantum computing becomes commonplace, hackers will use the technology to crack conventional encryption.

<p>"We have to be thinking about solutions to the problems that quantum computing will pose," he told the Telegraph. "The average consumer is going to want to know their own transactions and daily business is secure.</p>

<p>"One way of doing this is to use a one time pad  essentially lists of random numbers where one copy of the numbers is held by the person sending the information and an identical copy is held by the person receiving the information. These are completely unbreakable when used properly," he explained.</p>

<p>The critical feature of quantum computing is the unique fact that, if someone tampers with an information feed between two parties, then the nature of the quantum feed changes.</p>

<p>This makes eavesdropping impossible.</blockquote></p>

<p>No, it wouldn't make eavesdropping impossible.  It would make eavesdropping <i>on the communications channel</i> impossible unless someone made an implementation error.  (In the 80s, the NSA broke Soviet one-time-pad systems because the Soviets reused the pad.)  Eavesdropping via spyware or Trojan or TEMPEST would still be possible.</p><div class="feedflare">
<a href="http://feeds.feedburner.com/~f/schneier/fulltext?a=NpW5M"><img src="http://feeds.feedburner.com/~f/schneier/fulltext?i=NpW5M" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/schneier/fulltext?a=NzQ5M"><img src="http://feeds.feedburner.com/~f/schneier/fulltext?i=NzQ5M" border="0"></img></a>
</div>]]></content:encoded>
      <pubDate>Tue, 21 Oct 2008 02:48:49 +0000</pubDate>
      <category domain="http://securityratty.com/tag/cryptography">cryptography</category>
      <category domain="http://securityratty.com/tag/quantum cryptography">quantum cryptography</category>
      <category domain="http://securityratty.com/tag/quantum">quantum</category>
      <category domain="http://securityratty.com/tag/quantum-key distribution network">quantum-key distribution network</category>
      <category domain="http://securityratty.com/tag/quantum channel">quantum channel</category>
      <category domain="http://securityratty.com/tag/quantum system">quantum system</category>
      <category domain="http://securityratty.com/tag/quantum-key distribution technique">quantum-key distribution technique</category>
      <category domain="http://securityratty.com/tag/quantum feed">quantum feed</category>
      <category domain="http://securityratty.com/tag/quantum crypto">quantum crypto</category>
      <source url="http://www.schneier.com/blog/archives/2008/10/quantum_cryptog.html">Quantum Cryptography</source>
    </item>
    <item>
      <title><![CDATA[Quantum Cryptography: As Awesome As It Is Pointless]]></title>
      <link>http://securityratty.com/article/02906355879678e055ed7a962ad11336</link>
      <guid>http://securityratty.com/article/02906355879678e055ed7a962ad11336</guid>
      <description><![CDATA[Quantum cryptography is back in the news, and the basic idea is still unbelievably cool, in theory, and nearly useless in real life
The idea behind quantum crypto is that two people communicating...]]></description>
      <content:encoded><![CDATA[<p>
Quantum cryptography is back in the news, and the basic idea is still unbelievably cool, in theory, and nearly useless in real life.
</p><p>
The idea behind quantum crypto is that two people communicating using a quantum channel can be absolutely sure no one is eavesdropping.  Heisenberg's uncertainty principle requires anyone measuring a quantum system to disturb it, and that disturbance alerts legitimate users as to the eavesdropper's presence.  No disturbance, no eavesdropper — period.
</p><p>
This month we've seen reports on a new <a href="http://news.bbc.co.uk/2/hi/science/nature/7661311.stm">working</a> quantum-key distribution <a href="http://news.cnet.com/8301-1009_3-10064219-83.html?part=rss&subj=news&tag=2547-1_3-0-5">network</a> in Vienna, and a new quantum-key distribution <a href="http://www.theregister.co.uk/2008/10/09/quantum_crypto_turbo_charged/">technique</a> out of Britain. Great stuff, but headlines like the BBC's "'Unbreakable' encryption unveiled" are a bit much.
 </p><p>
The basic science behind quantum crypto was developed, and prototypes built, in the early 1980s by Charles Bennett and Giles Brassard, and there have been <a href="http://www.cs.mcgill.ca/~crepeau/CRYPTO/Biblio-QC.html">steady advances</a> in engineering since then. I describe basically how it all works in <cite>Applied Cryptography, 2nd Edition</cite> (pages 554-557). At least one company already <a href="http://www.magiqtech.com/">sells</a> quantum-key distribution products.
</p><p>
Note that this is totally separate from <a href="http://en.wikipedia.org/wiki/Quantum_computer">quantum computing</a>, which also has implications for cryptography. Several groups are working on designing and building a quantum computer, which is fundamentally different from a classical computer. If one were built — and we're talking science fiction here — then it could factor numbers and solve discrete-logarithm problems very quickly. In other words, it could break all of our commonly used public-key algorithms. For symmetric cryptography it's not that dire: A quantum computer would effectively halve the key length, so that a 256-bit key would be only as secure as a 128-bit key today. Pretty serious stuff, but years away from being practical. I think the best quantum computer today can factor the number 15.
</p><p>
While I like the science of quantum cryptography — my undergraduate degree was in physics — I don't see any commercial value in it. I don't believe it solves any security problem that needs solving. I don't believe that it's worth paying for, and I can't imagine anyone but a few technophiles buying and deploying it. Systems that use it don't magically become unbreakable, because the quantum part doesn't address the weak points of the system.
</p><p>
Security is a chain; it's as strong as the weakest link. Mathematical cryptography, as bad as it sometimes is, is the strongest link in most security chains. Our symmetric and public-key algorithms are pretty good, even though they're not based on much rigorous mathematical theory. The real problems are elsewhere: computer security, network security, user interface and so on.
</p><p>
Cryptography is the one area of security that we can get right. We already have good encryption algorithms, good authentication algorithms and good key-agreement protocols.  Maybe quantum cryptography can make that link stronger, but why would anyone bother? There are far more serious security problems to worry about, and it makes much more sense to spend effort securing those. 
</p><p>
As I've often said, it's like defending yourself against an approaching attacker by putting a huge stake in the ground. It's useless to argue about whether the stake should be 50 feet tall or 100 feet tall, because either way, the attacker is going to go around it. Even quantum cryptography doesn't "solve" all of cryptography: The keys are exchanged with photons, but a conventional mathematical algorithm takes over for the actual encryption. 
</p><p>
I'm always in favor of security research, and I have enjoyed following the developments in quantum cryptography. But as a product, it has no future. It's not that quantum cryptography might be insecure; it's that cryptography is already sufficiently secure.
</p>
<p> 
---
</p> 
<p><em>Bruce Schneier is chief security technology officer of BT. His new book is </em>Schneier on Security<em>.</em> 
</p><br style="clear: both;"/>
  <img alt="" style="border: 0; height:1px; width:1px;" border="0" src="http://www.pheedo.com/img.phdo?i=c1b0ca00ac0f95597bf221ad5e5c5153" height="1" width="1"/>
<img src="http://www.pheedo.com/feeds/tracker.php?i=c1b0ca00ac0f95597bf221ad5e5c5153" style="display: none;" border="0" height="1" width="1" alt=""/><div class="feedflare">
<a href="http://feeds.feedburner.com/~f/wired/politics/privacy?a=UswCM"><img src="http://feeds.feedburner.com/~f/wired/politics/privacy?i=UswCM" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/wired/politics/privacy?a=wtl5m"><img src="http://feeds.feedburner.com/~f/wired/politics/privacy?i=wtl5m" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/wired/politics/privacy?a=Lo9gm"><img src="http://feeds.feedburner.com/~f/wired/politics/privacy?i=Lo9gm" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/wired/politics/privacy?a=TTT2M"><img src="http://feeds.feedburner.com/~f/wired/politics/privacy?i=TTT2M" border="0"></img></a>
 <a href="http://feeds.wired.com/~f/wired/politics/security?a=FO1rM"><img src="http://feeds.wired.com/~f/wired/politics/security?i=FO1rM" border="0"></img></a> <a href="http://feeds.wired.com/~f/wired/politics/security?a=gniBm"><img src="http://feeds.wired.com/~f/wired/politics/security?i=gniBm" border="0"></img></a> <a href="http://feeds.wired.com/~f/wired/politics/security?a=XHBrm"><img src="http://feeds.wired.com/~f/wired/politics/security?i=XHBrm" border="0"></img></a> <a href="http://feeds.wired.com/~f/wired/politics/security?a=nRLbM"><img src="http://feeds.wired.com/~f/wired/politics/security?i=nRLbM" border="0"></img></a> </div><img src="http://feeds.feedburner.com/~r/wired/politics/privacy/~4/422243670" height="1" width="1"/><img src="http://feeds.wired.com/~r/wired/politics/security/~4/422243671" height="1" width="1"/>]]></content:encoded>
      <pubDate>Thu, 16 Oct 2008 00:00:00 +0000</pubDate>
      <category domain="http://securityratty.com/tag/quantum">quantum</category>
      <category domain="http://securityratty.com/tag/quantum cryptography">quantum cryptography</category>
      <category domain="http://securityratty.com/tag/cryptography">cryptography</category>
      <category domain="http://securityratty.com/tag/quantum-key distribution technique">quantum-key distribution technique</category>
      <category domain="http://securityratty.com/tag/quantum-key distribution network">quantum-key distribution network</category>
      <category domain="http://securityratty.com/tag/quantum crypto">quantum crypto</category>
      <category domain="http://securityratty.com/tag/security">security</category>
      <category domain="http://securityratty.com/tag/quantum channel">quantum channel</category>
      <category domain="http://securityratty.com/tag/computer security">computer security</category>
      <source url="http://feeds.wired.com/~r/wired/politics/security/~3/422243671/securitymatters_1016">Quantum Cryptography: As Awesome As It Is Pointless</source>
    </item>
    <item>
      <title><![CDATA[Microsofts Experimental Security Fix Is Actually A Malware]]></title>
      <link>http://securityratty.com/article/2fb512c7eafbbaa455422e54bf27e5b0</link>
      <guid>http://securityratty.com/article/2fb512c7eafbbaa455422e54bf27e5b0</guid>
      <description><![CDATA[Microsoft warned Monday about fake e-mails sent by scammers that claim to include critical Windows security alerts. The fake alerts describe themselves as part of a new experimental private version of...]]></description>
      <content:encoded><![CDATA[Microsoft warned Monday about fake e-mails sent by scammers that claim to include critical Windows security alerts. The fake alerts describe themselves as part of a new &#8220;experimental private version of an update for all Microsoft Windows OS users, according to Microsoft&#8217;s note on the scam.
The e-mails then instruct the victim to download an attachment, [...]]]></content:encoded>
      <pubDate>Mon, 13 Oct 2008 20:24:27 +0000</pubDate>
      <category domain="http://securityratty.com/tag/e-mails">e-mails</category>
      <category domain="http://securityratty.com/tag/fake alerts describe">fake alerts describe</category>
      <category domain="http://securityratty.com/tag/microsoft">microsoft</category>
      <category domain="http://securityratty.com/tag/fake e-mails">fake e-mails</category>
      <category domain="http://securityratty.com/tag/microsoft windows">microsoft windows</category>
      <category domain="http://securityratty.com/tag/experimental">experimental</category>
      <category domain="http://securityratty.com/tag/microsofts note">microsofts note</category>
      <category domain="http://securityratty.com/tag/users">users</category>
      <category domain="http://securityratty.com/tag/monday">monday</category>
      <source url="http://cyberinsecure.com/microsofts-experimental-security-fix-is-actually-a-malware/">Microsofts Experimental Security Fix Is Actually A Malware</source>
    </item>
    <item>
      <title><![CDATA[Why Risk Management Doesnt Work (?!)]]></title>
      <link>http://securityratty.com/article/2dce81ab5be406fb5211a9daea174b0c</link>
      <guid>http://securityratty.com/article/2dce81ab5be406fb5211a9daea174b0c</guid>
      <description><![CDATA[Several folks (Hi Daniel , Brent , David !) sent email &amp; twitters asking us our opinion on a Dark Reading article called Why Risk Management Doesnt Work which if you click on the link should come up...]]></description>
      <content:encoded><![CDATA[<p>Several folks (Hi <a href="http://dmiessler.com/">Daniel</a>, <a href="http://stateofsecurity.com/">Brent</a>, <a href="http://www.twitter.com/debix">David</a>!) sent email &amp; twitters asking us our opinion on a Dark Reading article called &#8220;<a href="http://www.darkreading.com/document.asp?doc_id=165107">Why Risk Management Doesn&#8217;t Work</a>&#8221; which if you click on the link should come up for you after seeing someone&#8217;s advertisement for a few seconds.</p>
<p>I&#8217;m assuming the author wants us to read the title as <strong>&#8220;Things to Look Out For in Performing Risk Analysis&#8221;</strong> and not <strong>&#8220;Risk Management is Folly - Stop, Stop, Stop!&#8221;</strong> The former is fine, the latter isn&#8217;t supported by the evidence presented by the subjects of the article.<br />
The subjects of the article are a <strong><a href="http://www.verizonbusiness.com/resources/security/databreachreport.pdf">good study from Wade Baker &amp; Co. at Verizon</a></strong>, and a report from RSA&#8217;s Security for Business Innovation Council. Let&#8217;s take a look at each of these and examine why what they&#8217;re saying might contribute to poor risk management, shall we?</p>
<p><strong>1.)  THE VERIZON REPORT</strong></p>
<p>The Verizon report is an analysis of some 530 forensic investigations their company performed.  It is well worth your time as it&#8217;s chock full of interesting information.  As it relates to the Dark Reading piece, a coarse summary would be that &#8220;likelihood&#8221; is &#8220;different&#8221; for different people and so you can&#8217;t use the same &#8220;likelihood&#8221; across different industries.</p>
<p>Distilled through the lens of FAIR:</p>
<blockquote><p>&#8220;different threat communities may be applicable based on Probability of Action factors which include: Value, Level of Effort and Risk (of Getting Caught).&#8221;</p></blockquote>
<p>Or, even further distilled and in the words of my six year old son,</p>
<blockquote><p>&#8220;Duh-uh&#8221;.</p></blockquote>
<p>With regards to what I assume is the purpose of the article (What Doesn&#8217;t Work in Risk Analysis) this concept  seems just to rehash the old GIGO argument regarding risk analysis.  Great.  Can&#8217;t argue with that, nor it&#8217;s corollary QIQO (quality in, quality out).</p>
<p>But let me ask you -  <strong><em>is this really a problem common in your analysis</em></strong>?  Did reading this article make you go &#8220;Crap, we&#8217;ve been using data normalized across multiple industries in our analysis! They&#8217;re all wrong!&#8221;  Or have you already been accounting for the unique value proposition your company has to the specific threat community you&#8217;re worried about?  See, maybe I&#8217;m just not your average analyst, but even in my NIST/OCTAVE days, this has *never* been an issue for me.</p>
<p>Let me be specific, this is not a problem with Verizon&#8217;s very cool report.  It&#8217;s just that I don&#8217;t see what the big deal is.  This article is starting to feel like someone is running through the motions, trying to play the &#8221; a crazy title gets people to read a boring article&#8221; game.</p>
<p>Speaking of cool reports - You know what would be cool?  I think it would be interesting to see is the quality of these companies&#8217; &#8220;risk management process&#8221; established using good criteria,  and then correlated to the frequency and magnitude of real-world losses across the aggregate sample.  In other words, can we establish evidence that strong risk management practices not just reduce &#8220;risk&#8221; but also reduce actual incidents.</p>
<p><strong>2.)  THE RSA COUNCIL &#8220;EXPLORES WHY LEGACY METHODS OF EVALUATING INFORMATION SECURITY RISK DON&#8217;T WORK IN TODAY&#8217;S CONNECTED WORLD, IN WHICH ANY NEW BUSINESS INNOVATION INHERENTLY CARRIES SOME LEVEL OF RISK TO INFORMATION.&#8221;</strong></p>
<p>This report from the RSA council puts forth a seemingly obvious proposition, that risk must be balanced by reward.  Why is this news?  Now as I read the article it&#8217;s not clear if:</p>
<ul>
<li>The RSA Council is claiming that the CISO&#8217;s office should be the ones determining reward.  Absurd.</li>
</ul>
<p>or</p>
<ul>
<li>Businesses aren&#8217;t doing a good job at determining risk and reward.</li>
</ul>
<p>Let&#8217;s go with the latter.  So I&#8217;m pretty sure (good) businesses do a good job at estimating reward.  Businesses I&#8217;ve been a part of?  We LOVE(D) estimating reward.  We don&#8217;t tend to start projects all willy-nilly. No we tend to be careful to identify the size of the market and what it will cost to address the market.  So what could the problem be that this RSA council is trying to address?  Maybe it has to do with something like the following:</p>
<p>Yesterday, I got a demo of an IT-GRC application that shall remain nameless.  It seemed to be very good at the &#8220;C&#8221; bits - lots of information on regulations and expectations and even what sorts of controls would answer the regulations (which is goofy, but we&#8217;ll have to talk about that later).  It also gave you the ability to build workflow quite nicely.  But it measured NOTHING.  There really was no observable &#8220;G&#8221; and &#8220;R&#8221; was really Medium X Low X Low = High sorts of stuff.  So let&#8217;s use this relatively expensive tool as evidence of what your average CISO is armed with going into a Risk/Reward sort of meeting.  I imagine a nice board room with wood-grain paneling and glass bowls filled with little chocolate covered mints designed to give everyone involved in the meeting (CEO, CFO, CIO, CSO, VP S&amp;M, etc&#8230;) a little sugar rush when needed and fresh breath.  The conversation goes a little something like this (apologies to <strong><a href="http://securosis.com/2008/09/17/the-fallacy-of-complete-and-accurate-risk-quantification/">Rich</a></strong>):</p>
<blockquote><p><em><strong>Business Guy Who Wants to Make Money Because That&#8217;s What Businesses Do:</strong></em> Based on market studies, we believe that initial gross revenues from the new product and technology rollout will be eleventy gazillion dollars based on a 37% market penetration in Scandinavia, alone.</p>
<p><em><strong>CSO: </strong></em> Well now, we have a likelihood of &#8220;High&#8221; and a &#8220;C&#8221; impact of Medium, and an &#8220;I&#8221; impact of Low, and an &#8220;A&#8221; impact of &#8220;High&#8221; and because we are a (bank/hospital/retailer/basically any business that breathes anymore) we weight &#8220;C&#8221; by a factor of 2 - we multiplied those all together and got a &#8220;High&#8221;.</p>
<p>So can you guys delay the product rollout by 9 months and give me a bunch more money that&#8217;s not in the budget so that I can get this thing down to a &#8220;Medium&#8221;, please?</p></blockquote>
<p>Again, I just don&#8217;t see the problem with Information Risk Management being that our businesses have no idea what the rewards of business might be.  Now maybe we need get a seat in that boardroom just to be able to talk about our &#8220;Mediums&#8221;, sure.  And maybe we&#8217;re infantile in our ability to describe our problem space.  But I cannot fathom that &#8220;<em>Risk Management Doesn&#8217;t Work</em>&#8221; because businesses haven&#8217;t been considering &#8220;reward&#8221;.</p>
<p><strong>WHY RISK MANAGEMENT MAY  NOT BE WORKIN&#8217; FOR YOU</strong></p>
<p>Two meta-categories of causation:</p>
<ul>
<li>No skills</li>
</ul>
<p>and/or</p>
<ul>
<li>No resources</li>
</ul>
<p>Any ancillary &#8220;cause&#8221; can be mapped to one of these categories.  You could have significant resources but crappy models, and have conversations like our imaginary CSO, above.  You could have really good models and people trained and motivated to use them, but scarce time &amp; money, so no conversation happens.</p>
<p>Now my question for you is - which does it make sense to acquire *first* to solve the &#8220;<em>Why Risk Management Doesn&#8217;t Work</em>&#8221; problems, skills or resources?</p>
]]></content:encoded>
      <pubDate>Wed, 08 Oct 2008 13:15:14 +0000</pubDate>
      <category domain="http://securityratty.com/tag/risk management">risk management</category>
      <category domain="http://securityratty.com/tag/information">information</category>
      <category domain="http://securityratty.com/tag/information risk management">information risk management</category>
      <category domain="http://securityratty.com/tag/risk">risk</category>
      <category domain="http://securityratty.com/tag/poor risk management">poor risk management</category>
      <category domain="http://securityratty.com/tag/information security risk">information security risk</category>
      <category domain="http://securityratty.com/tag/reduce risk">reduce risk</category>
      <category domain="http://securityratty.com/tag/risk analysis">risk analysis</category>
      <category domain="http://securityratty.com/tag/cool report">cool report</category>
      <source url="http://riskmanagementinsight.com/riskanalysis/?p=459">Why Risk Management Doesnt Work (?!)</source>
    </item>
    <item>
      <title><![CDATA[Revealing Packed Malware]]></title>
      <link>http://securityratty.com/article/f80d94b6a1f4dade57ea3122522abdb5</link>
      <guid>http://securityratty.com/article/f80d94b6a1f4dade57ea3122522abdb5</guid>
      <description><![CDATA[In concert with the ever-growing network applications, a significant increase in the spread of malware over the Internet has been observed. In cases where malware are the zero-day threats, generating...]]></description>
      <content:encoded><![CDATA[In concert with the ever-growing network applications, a significant increase in the spread of malware over the Internet has been observed. In cases where malware are the zero-day threats, generating their signatures for detection via anti-virus (AV) scan engines becomes an important reactive security function. However, modern malware can easily bypass AV scanners using packers, which can hide malicious file contents from detection. This article describes how packers work, and the three most commonly used unpacking methods. The authors describe the logic flow and behavior of Upack, a popular packer, as an example of a software packer.<br style="clear: both;"/>
  <img alt="" style="border: 0; height:1px; width:1px;" border="0" src="http://www.pheedo.com/img.phdo?i=e2d0c6f8959f9790ec29a49937b08486" height="1" width="1"/>
<img src="http://www.pheedo.com/feeds/tracker.php?i=e2d0c6f8959f9790ec29a49937b08486" style="display: none;" border="0" height="1" width="1" alt=""/>]]></content:encoded>
      <pubDate>Wed, 08 Oct 2008 00:42:07 +0000</pubDate>
      <category domain="http://securityratty.com/tag/malware">malware</category>
      <category domain="http://securityratty.com/tag/modern malware">modern malware</category>
      <category domain="http://securityratty.com/tag/reactive security function">reactive security function</category>
      <category domain="http://securityratty.com/tag/authors describe">authors describe</category>
      <category domain="http://securityratty.com/tag/detection">detection</category>
      <category domain="http://securityratty.com/tag/network applications">network applications</category>
      <category domain="http://securityratty.com/tag/software packer">software packer</category>
      <category domain="http://securityratty.com/tag/scan engines">scan engines</category>
      <category domain="http://securityratty.com/tag/zero-day threats">zero-day threats</category>
      <source url="http://www.pheedo.com/click.phdo?i=e2d0c6f8959f9790ec29a49937b08486">Revealing Packed Malware</source>
    </item>
    <item>
      <title><![CDATA[Virtual Machine Introspection: Observation or Interference?]]></title>
      <link>http://securityratty.com/article/d1c6610de201f53ac191754bc494d71c</link>
      <guid>http://securityratty.com/article/d1c6610de201f53ac191754bc494d71c</guid>
      <description><![CDATA[As virtualization becomes increasingly mainstream, virtual machine introspection techniques and tools are evolving to provide methods to monitor the behavior of virtual machines. This survey...]]></description>
      <content:encoded><![CDATA[As virtualization becomes increasingly mainstream, virtual machine introspection techniques and tools are evolving to provide methods to monitor the behavior of virtual machines. This survey classifies and describes current VMI introspection technologies according to three primary classifications: threat monitoring versus interference, semantic awareness, and event replay. The authors also describe the Virtual Introspection for Xen (VIX) tool suite, which was developed to address key VMI requirements, and outline key research areas for future investigation.<br style="clear: both;"/>
      <a href="http://www.pheedo.com/click.phdo?s=41e08c548c8eab8a20dd182ad564facb"><img alt="" style="border: 0;" border="0" src="http://www.pheedo.com/img.phdo?s=41e08c548c8eab8a20dd182ad564facb"/></a>
  <img src="http://www.pheedo.com/feeds/tracker.php?i=41e08c548c8eab8a20dd182ad564facb" style="display: none;" border="0" height="1" width="1" alt=""/>]]></content:encoded>
      <pubDate>Wed, 08 Oct 2008 00:42:05 +0000</pubDate>
      <category domain="http://securityratty.com/tag/outline key research">outline key research</category>
      <category domain="http://securityratty.com/tag/semantic awareness">semantic awareness</category>
      <category domain="http://securityratty.com/tag/future investigation">future investigation</category>
      <category domain="http://securityratty.com/tag/tool suite">tool suite</category>
      <category domain="http://securityratty.com/tag/increasingly mainstream">increasingly mainstream</category>
      <category domain="http://securityratty.com/tag/provide methods">provide methods</category>
      <category domain="http://securityratty.com/tag/virtual machines">virtual machines</category>
      <category domain="http://securityratty.com/tag/virtual introspection">virtual introspection</category>
      <category domain="http://securityratty.com/tag/event replay">event replay</category>
      <source url="http://www.pheedo.com/click.phdo?i=41e08c548c8eab8a20dd182ad564facb">Virtual Machine Introspection: Observation or Interference?</source>
    </item>
    <item>
      <title><![CDATA[The McAfee Secure Standard: Sort Of]]></title>
      <link>http://securityratty.com/article/93a923291bb66872facd096a29cc894d</link>
      <guid>http://securityratty.com/article/93a923291bb66872facd096a29cc894d</guid>
      <description><![CDATA[I need your help
I am in receipt of the McAfee Secure Standard, drafted to transparently describe the McAfee Secure service, as promised during my meeting with Joe Pierini and Kirk Lawrence of McAfee...]]></description>
      <content:encoded><![CDATA[I need your help.<br />I am in receipt of the McAfee Secure Standard, drafted to transparently describe the McAfee Secure service, as promised during my <a href="http://holisticinfosec.blogspot.com/2008/08/mcirony-unexpected-response-from-mcafee.html" target="_blank">meeting</a> with Joe Pierini and Kirk Lawrence of McAfee some weeks ago. I admit my attitude has soured since last I discussed it here, as the Standard is not yet ready for public release (I last said 2-3 weeks and that was five weeks ago), but bear with me. I can't publish exact quotes from the Standard, as I've promised not to, but let me give you insight on the upside, then the downside.<br /><br />The upside includes all the transparency we'd hoped for. You'll read the McAfee Secure Standard and know exactly where they stand with regard as to what can be expected of the McAfee Secure Service. My discussions with Joe Pierini have been productive and respectful, he means well, and I believe he will try to drive the greater McAfee leadership to officially incorporate suggestions made in this blog. <br />I have even had the pleasure of reading a Researcher/Finder Policy that very succinctly describes what researchers can expect when they submit vulnerabilities found in McAfee Secure sites. That's all good stuff and to be applauded.<br /><br />Now for the downside.<br /><br />The McAfee Secure Standard will draw a clear distinction between "enterprise" customers and all the Ma & Pa websites who have so loved McAfee Secure / ScanAlert Hacker Safe for conversions.<br />The most glaring and painful distinction for me is this. While enterprise customers will have a clearly defined time line in which to remediate script injection vulnerabilities like XSS and open redirects, before losing their McAfee Secure badge, <span style="font-weight:bold;">the Ma & Pa sites will have absolutely no requirement to fix their XSS issues</span>. XSS vulnerabilities and the McAfee Secure badge will remain consistent on all those sites that care more about "convincing" their customers that they're secure with a McAfee Secure badge; a badge that, by its own pending standard, will contradict what we know to be truly secure.<br /><br />My views are clear. I have made every effort to convince McAfee that this stance is counter intuitive to good web application security standards. I believe that, in their own way, they are listening. So here's your chance.<br />1) Is transparency enough?<br />2) Is holding only enterprise customers accountable acceptable?<br />3) Should ALL McAfee Secure customers be expected to fix their vulnerabilities, even if on different timelines?<br />4) What else do you want McAfee to hear, in the form of constructive feedback only?<br />I will publish all well written, thoughtful comments here. Let's keep it positive and see if we can help convince McAfee that script injection vulnerabilities and McAfee Secure can't exist in the same physical space. Like matter and anti-matter. ;-)<br />The floor is yours...<br /><br /><a href="http://del.icio.us/post?url=http://holisticinfosec.blogspot.com/2008/10/mcafee-secure-standard-sort-of.html&title=The%20McAfee%20Secure%20Standard:%20Sort%20Of " title="The McAfee Secure Standard: Sort Of ">del.icio.us</a> | <a href="http://digg.com/submit?phase=2&amp;url=http://holisticinfosec.blogspot.com/2008/10/mcafee-secure-standard-sort-of.html" title="The McAfee Secure Standard: Sort Of ">digg</a> | <a href="http://slashdot.org/submit.pl?url=http://holisticinfosec.blogspot.com/2008/10/mcafee-secure-standard-sort-of.html">Submit to Slashdot</a>]]></content:encoded>
      <pubDate>Tue, 07 Oct 2008 19:47:00 +0000</pubDate>
      <category domain="http://securityratty.com/tag/mcafee">mcafee</category>
      <category domain="http://securityratty.com/tag/mcafee secure customers">mcafee secure customers</category>
      <category domain="http://securityratty.com/tag/sites">sites</category>
      <category domain="http://securityratty.com/tag/mcafee secure sites">mcafee secure sites</category>
      <category domain="http://securityratty.com/tag/mcafee secure standard">mcafee secure standard</category>
      <category domain="http://securityratty.com/tag/mcafee secure service">mcafee secure service</category>
      <category domain="http://securityratty.com/tag/mcafee secure">mcafee secure</category>
      <category domain="http://securityratty.com/tag/loved mcafee secure">loved mcafee secure</category>
      <category domain="http://securityratty.com/tag/convince mcafee">convince mcafee</category>
      <source url="http://holisticinfosec.blogspot.com/2008/10/mcafee-secure-standard-sort-of.html">The McAfee Secure Standard: Sort Of</source>
    </item>
    <item>
      <title><![CDATA[The Seven Habits of Highly Ineffective Terrorists]]></title>
      <link>http://securityratty.com/article/9ded3dd1627a4f9a60f16de4625687eb</link>
      <guid>http://securityratty.com/article/9ded3dd1627a4f9a60f16de4625687eb</guid>
      <description><![CDATA[Most counterterrorism policies fail, not because of tactical problems, but because of a fundamental misunderstanding of what motivates terrorists in the first place. If we're ever going to defeat...]]></description>
      <content:encoded><![CDATA[<p>Most counterterrorism policies fail, not because of tactical problems, but because of a fundamental misunderstanding of what motivates terrorists in the first place. If we're ever going to defeat terrorism, we need to understand what drives people to become terrorists in the first place. </p>

<p>Conventional wisdom holds that terrorism is inherently political, and that people become terrorists for political reasons. This is the "strategic" model of terrorism, and it's basically an economic model. It posits that people resort to terrorism when they believe -- rightly or wrongly -- that terrorism is worth it; that is, when they believe the political gains of terrorism minus the political costs are greater than if they engaged in some other, more peaceful form of protest. It's assumed, for example, that people join Hamas to achieve a Palestinian state; that people join the PKK to attain a Kurdish national homeland; and that people join al-Qaida to, among other things, get the United States out of the Persian Gulf. </p>

<p>If you believe this model, the way to fight terrorism is to change that equation, and that's what most experts advocate. Governments tend to minimize the political gains of terrorism through a no-concessions policy; the international community tends to recommend reducing the political grievances of terrorists via appeasement, in hopes of getting them to renounce violence. Both advocate policies to provide effective nonviolent alternatives, like free elections. </p>

<p>Historically, none of these solutions has worked with any regularity. Max Abrahms, a predoctoral fellow at Stanford University's Center for International Security and Cooperation, has studied dozens of terrorist groups from all over the world. He argues that the model is wrong. In a <a href="http://maxabrahms.com/pdfs/DC_250-1846.pdf">paper</a> published this year in International Security that -- sadly -- doesn't have the title "Seven Habits of Highly Ineffective Terrorists," he discusses, well, seven habits of highly ineffective terrorists. These seven tendencies are seen in terrorist organizations all over the world, and they directly contradict the theory that terrorists are political maximizers: </p>

<p>Terrorists, he writes, (1) attack civilians, a policy that has a lousy track record of convincing those civilians to give the terrorists what they want; (2) treat terrorism as a first resort, not a last resort, failing to embrace nonviolent alternatives like elections; (3) don't compromise with their target country, even when those compromises are in their best interest politically; (4) have protean political platforms, which regularly, and sometimes radically, change; (5) often engage in anonymous attacks, which precludes the target countries making political concessions to them; (6) regularly attack other terrorist groups with the same political platform; and (7) resist disbanding, even when they consistently fail to achieve their political objectives or when their stated political objectives have been achieved. </p>

<p>Abrahms has an alternative model to explain all this: People turn to terrorism for social solidarity. He theorizes that people join terrorist organizations worldwide in order to be part of a community, much like the reason inner-city youths join gangs in the United States. </p>

<p>The evidence supports this. Individual terrorists often have no prior involvement with a group's political agenda, and often join multiple terrorist groups with incompatible platforms. Individuals who join terrorist groups are frequently not oppressed in any way, and often can't describe the political goals of their organizations. People who join terrorist groups most often have friends or relatives who are members of the group, and the great majority of terrorist are socially isolated: unmarried young men or widowed women who weren't working prior to joining. These things are true for members of terrorist groups as diverse as the IRA and al-Qaida. </p>

<p>For example, several of the 9/11 hijackers planned to fight in Chechnya, but they didn't have the right paperwork so they attacked America instead. The mujahedeen had no idea whom they would attack after the Soviets withdrew from Afghanistan, so they sat around until they came up with a new enemy: America. Pakistani terrorists regularly defect to another terrorist group with a totally different political platform. Many new al-Qaida members say, unconvincingly, that they decided to become a jihadist after reading an extreme, anti-American blog, or after converting to Islam, sometimes just a few weeks before. These people know little about politics or Islam, and they frankly don't even seem to care much about learning more. The blogs they turn to don't have a lot of substance in these areas, even though more informative blogs do exist. </p>

<p>All of this explains the seven habits. It's not that they're ineffective; it's that they have a different goal. They might not be effective politically, but they are effective socially: They all help preserve the group's existence and cohesion. </p>

<p>This kind of analysis isn't just theoretical; it has practical implications for counterterrorism. Not only can we now better understand who is likely to become a terrorist, we can engage in strategies specifically designed to weaken the social bonds within terrorist organizations. Driving a wedge between group members -- commuting prison sentences in exchange for actionable intelligence, planting more double agents within terrorist groups -- will go a long way to weakening the social bonds within those groups. </p>

<p>We also need to pay more attention to the socially marginalized than to the politically downtrodden, like unassimilated communities in Western countries. We need to support vibrant, benign communities and organizations as alternative ways for potential terrorists to get the social cohesion they need. And finally, we need to minimize collateral damage in our counterterrorism operations, as well as clamping down on bigotry and hate crimes, which just creates more dislocation and social isolation, and the inevitable calls for revenge.</p>

<p>This essay <a href="http://www.wired.com/print/politics/security/commentary/securitymatters/2008/10/securitymatters_1002">previously appeared</a> on Wired.com.</p><div class="feedflare">
<a href="http://feeds.feedburner.com/~f/schneier/fulltext?a=QW5fM"><img src="http://feeds.feedburner.com/~f/schneier/fulltext?i=QW5fM" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/schneier/fulltext?a=YCnjM"><img src="http://feeds.feedburner.com/~f/schneier/fulltext?i=YCnjM" border="0"></img></a>
</div>]]></content:encoded>
      <pubDate>Tue, 07 Oct 2008 01:48:53 +0000</pubDate>
      <category domain="http://securityratty.com/tag/ineffective">ineffective</category>
      <category domain="http://securityratty.com/tag/highly ineffective terrorists">highly ineffective terrorists</category>
      <category domain="http://securityratty.com/tag/terrorists">terrorists</category>
      <category domain="http://securityratty.com/tag/people join">people join</category>
      <category domain="http://securityratty.com/tag/people join hamas">people join hamas</category>
      <category domain="http://securityratty.com/tag/people join al-qaida">people join al-qaida</category>
      <category domain="http://securityratty.com/tag/terrorist organizations">terrorist organizations</category>
      <category domain="http://securityratty.com/tag/organizations">organizations</category>
      <category domain="http://securityratty.com/tag/al-qaida">al-qaida</category>
      <source url="http://www.schneier.com/blog/archives/2008/10/the_seven_habit.html">The Seven Habits of Highly Ineffective Terrorists</source>
    </item>
  </channel>
</rss>
