<?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: Six Sigma and App Security</title>
	<atom:link href="http://episteme.ca/2009/03/20/six-sigma-and-app-security/feed/" rel="self" type="application/rss+xml" />
	<link>http://episteme.ca/2009/03/20/six-sigma-and-app-security/</link>
	<description></description>
	<lastBuildDate>Sat, 04 Feb 2012 10:41:30 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Why Information Security is the Hardest Career &#124; Information Security Leaders</title>
		<link>http://episteme.ca/2009/03/20/six-sigma-and-app-security/comment-page-1/#comment-2430</link>
		<dc:creator>Why Information Security is the Hardest Career &#124; Information Security Leaders</dc:creator>
		<pubDate>Tue, 10 Nov 2009 22:36:15 +0000</pubDate>
		<guid isPermaLink="false">http://episteme.ca/?p=580#comment-2430</guid>
		<description>[...] changing and we’re forced to keep up constantly. The simple reason behind that change is that security is ultimately a quality issue. What’s interesting about quality is that issues in product quality are heavily front-loaded – [...]</description>
		<content:encoded><![CDATA[<p>[...] changing and we’re forced to keep up constantly. The simple reason behind that change is that security is ultimately a quality issue. What’s interesting about quality is that issues in product quality are heavily front-loaded – [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MikeN</title>
		<link>http://episteme.ca/2009/03/20/six-sigma-and-app-security/comment-page-1/#comment-2151</link>
		<dc:creator>MikeN</dc:creator>
		<pubDate>Mon, 22 Jun 2009 21:02:06 +0000</pubDate>
		<guid isPermaLink="false">http://episteme.ca/?p=580#comment-2151</guid>
		<description>It sounds like you&#039;re both in agreement that a financial wrapper is required for C level execs to even look at application security.  The way I see it, there&#039;s 2 ways to frame the conversation 1) You&#039;re going to make X amount of money or 2) You&#039;re going to not lose Y amount of money.  

The problem with option 1 is unless you&#039;re going to build and sell a solution to secure you&#039;re application security, you&#039;re not going to make money on it.  It&#039;s a cost centre.

The problem with option 2 is, financial quantification of risk is a very difficult thing to do without sounding like chicken little.  Until a very tangible example of the described perceived loss is presented in the company, marketplace or media the C level exec can justify 100 other things to spend the money on.  

In my opinion, it&#039;s a lot like insurance.  Everyone hates it until you or someone close to you needs it, then you&#039;re glad you have it.  It would take a very open minded C level exec to start the trend, but even if you find one, how do you have that &quot;we saved umpteen million dollars&quot; moment that gets shared with the world?</description>
		<content:encoded><![CDATA[<p>It sounds like you&#8217;re both in agreement that a financial wrapper is required for C level execs to even look at application security.  The way I see it, there&#8217;s 2 ways to frame the conversation 1) You&#8217;re going to make X amount of money or 2) You&#8217;re going to not lose Y amount of money.  </p>
<p>The problem with option 1 is unless you&#8217;re going to build and sell a solution to secure you&#8217;re application security, you&#8217;re not going to make money on it.  It&#8217;s a cost centre.</p>
<p>The problem with option 2 is, financial quantification of risk is a very difficult thing to do without sounding like chicken little.  Until a very tangible example of the described perceived loss is presented in the company, marketplace or media the C level exec can justify 100 other things to spend the money on.  </p>
<p>In my opinion, it&#8217;s a lot like insurance.  Everyone hates it until you or someone close to you needs it, then you&#8217;re glad you have it.  It would take a very open minded C level exec to start the trend, but even if you find one, how do you have that &#8220;we saved umpteen million dollars&#8221; moment that gets shared with the world?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dwaynedibbly</title>
		<link>http://episteme.ca/2009/03/20/six-sigma-and-app-security/comment-page-1/#comment-1928</link>
		<dc:creator>dwaynedibbly</dc:creator>
		<pubDate>Mon, 23 Mar 2009 10:51:17 +0000</pubDate>
		<guid isPermaLink="false">http://episteme.ca/?p=580#comment-1928</guid>
		<description>So what we really need is a killer app that by it&#039;s very nature must developed and deployed  in the most assured way posible, that can act as a trojan horse (no pun intended) for bringing good quality practices (whatever they actually happen to be in the app-sec space) to the masses. I have a few thoughts on what that app should be (and it ain&#039;t DLP)! 

Fascinated to hear your thoughts on the translation/uses of manufacturing disciplines into security, it is rather apposite for myself at the moment. Personally I can see a lot of value in the Lean&#039;s pull methodology for creating self evidencing compliance controls - not exactly sexy, but necessary none the less.</description>
		<content:encoded><![CDATA[<p>So what we really need is a killer app that by it&#8217;s very nature must developed and deployed  in the most assured way posible, that can act as a trojan horse (no pun intended) for bringing good quality practices (whatever they actually happen to be in the app-sec space) to the masses. I have a few thoughts on what that app should be (and it ain&#8217;t DLP)! </p>
<p>Fascinated to hear your thoughts on the translation/uses of manufacturing disciplines into security, it is rather apposite for myself at the moment. Personally I can see a lot of value in the Lean&#8217;s pull methodology for creating self evidencing compliance controls &#8211; not exactly sexy, but necessary none the less.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mmurray</title>
		<link>http://episteme.ca/2009/03/20/six-sigma-and-app-security/comment-page-1/#comment-1927</link>
		<dc:creator>mmurray</dc:creator>
		<pubDate>Fri, 20 Mar 2009 20:34:53 +0000</pubDate>
		<guid isPermaLink="false">http://episteme.ca/?p=580#comment-1927</guid>
		<description>A couple of thoughts:

First, completely agree on the application of manufacturing discipline to security processes - they are different animals.  I have thoughts on the translation process between them, but that&#039;s out of scope for this conversation.

Second, you bring up the biggest problem in the whole appsec issue - in order to drive adoption, appsec has to create a tangible business benefit (in the same way that 6S/Lean drive efficiency and profitability in the long term) before we can have the large-scale business adoption.  

Is the current loss from a lack of app-sec enough of an impact on the business to make that worth doing?  I have no idea.  I have my thoughts, but none of them are more than wet-finger-in-the-air guesses. ;-) 

All I was really saying is that, if we&#039;re ever going to have mass-market penetration, we need those early adopters in the same way that Six Sigma needed GE &amp; Applied Signal and Lean needed Toyota.   We need to use the quality movement as a metaphor and a roadmap to organizational adoption.

I haven&#039;t seen that yet, which isn&#039;t going to make it something that CIOs recognize as valuable.</description>
		<content:encoded><![CDATA[<p>A couple of thoughts:</p>
<p>First, completely agree on the application of manufacturing discipline to security processes &#8211; they are different animals.  I have thoughts on the translation process between them, but that&#8217;s out of scope for this conversation.</p>
<p>Second, you bring up the biggest problem in the whole appsec issue &#8211; in order to drive adoption, appsec has to create a tangible business benefit (in the same way that 6S/Lean drive efficiency and profitability in the long term) before we can have the large-scale business adoption.  </p>
<p>Is the current loss from a lack of app-sec enough of an impact on the business to make that worth doing?  I have no idea.  I have my thoughts, but none of them are more than wet-finger-in-the-air guesses. <img src='http://episteme.ca/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />  </p>
<p>All I was really saying is that, if we&#8217;re ever going to have mass-market penetration, we need those early adopters in the same way that Six Sigma needed GE &#038; Applied Signal and Lean needed Toyota.   We need to use the quality movement as a metaphor and a roadmap to organizational adoption.</p>
<p>I haven&#8217;t seen that yet, which isn&#8217;t going to make it something that CIOs recognize as valuable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dwaynedibbly</title>
		<link>http://episteme.ca/2009/03/20/six-sigma-and-app-security/comment-page-1/#comment-1926</link>
		<dc:creator>dwaynedibbly</dc:creator>
		<pubDate>Fri, 20 Mar 2009 20:23:45 +0000</pubDate>
		<guid isPermaLink="false">http://episteme.ca/?p=580#comment-1926</guid>
		<description>This is indeed a rich topic for debate. For the sake of argument I&#039;ll adopt a more extreme position than is strictly appropriate. The blanket application of manufacturing paradigms to information security is at best misguided and at worst completely irrelevant. 
Two examples should focus things - fixing security flaws in word and building an IDS. Fixing security flaws in Word is a noble thing to do but from a manufacturing point of view it is a non-starter. Word is designed to help people create documents and communicate ideas. It should do this efficiently and effectively. That a bad guy can make word do nefarious things, whilst not good, is not part of the fundamental design brief that delivers a product to market that people will use and gain the penetration that lead to sustained profit. Lean and 6S in manufacturing are about delivering a product that consistently delivers to customer expectations within the parameters of acceptable use – fail at that and the commercial opportunity is lost. Lean delivers production efficient by eliminating waste, 6s by eliminating production defects.  If ones business is delivering security software, or implementing a secured system, like an IDS or payment system, then security is a functional requirement and therefore in scope of manufacturing paradigms.   A false-positive in an IDS is waste Lean should eliminate and evidence of a defective detection routine that 6S should cover. If a flaw in word can compramise a supposedly secure system, then it is not a failure of word, but in the defensive depth of the secured system. If a flaw in word can screw up or lose a document, then it is a failure of word. 
Now here’s the rub. What if 6S and Lean, expressed as organization qualities, had only peripheral effect on the success of the business? Toyota’s Lean techniques haven’t made people buy cars in the current down turn.  Lean is about efficiency. Name me one business for whom efficiency isn’t vitally important? 6S is about avoiding mass production mistakes. What business won’t benefit from that at some level except companies that succeed because of bespoke production for whom 6S isn’t that relevant? I don’t mean to undermine these things, they have delivered tremendous savings and efficiencies. But a vibrant market, flush with ready cash is far more important. The ecology of a business is the single biggest contributor to it’s success. If the market demands custom built then mass production won’t help. If the market don’t want what you sell, however good, then the product is a dud.  Looking at the success of previous companies and divining what made them work is very difficult. It is fraught with danger and bad assumptions. The Halo Effect by Rosenzweig (http://www.amazon.co.uk/Halo-Effect-Business-Delusions-Managers/dp/0743291255) describes the problems very well and is a must read!   Certainly the level of data needed to prove that these things are in-and-of-themselves recession beaters in today’s ‘noughties-are-the-new-thirties’ world is just not there.  
Quality is not free. To describe it as free implies perfection is free, which is demonstrably untrue. It takes practice, honesty, integrity, dedication and energy. Every industry needs that. If you want to sell application security it to C-level executives then prove that the security you deliver is what your customers actually want. But one has to remember from TX Maxx that customers are fickle beasts who’s memory length is inversely proportionate to the depth of their pockets, and aren’t apt to behave in totally rational ways. 
Am I right? I don’t know. All I know is that survival is based upon one’s reading of the world and adaptation to that information. More security is not always the right thing. Just ask the blacksmith forging a new sword with a suit of chain-mail on.</description>
		<content:encoded><![CDATA[<p>This is indeed a rich topic for debate. For the sake of argument I&#8217;ll adopt a more extreme position than is strictly appropriate. The blanket application of manufacturing paradigms to information security is at best misguided and at worst completely irrelevant.<br />
Two examples should focus things &#8211; fixing security flaws in word and building an IDS. Fixing security flaws in Word is a noble thing to do but from a manufacturing point of view it is a non-starter. Word is designed to help people create documents and communicate ideas. It should do this efficiently and effectively. That a bad guy can make word do nefarious things, whilst not good, is not part of the fundamental design brief that delivers a product to market that people will use and gain the penetration that lead to sustained profit. Lean and 6S in manufacturing are about delivering a product that consistently delivers to customer expectations within the parameters of acceptable use – fail at that and the commercial opportunity is lost. Lean delivers production efficient by eliminating waste, 6s by eliminating production defects.  If ones business is delivering security software, or implementing a secured system, like an IDS or payment system, then security is a functional requirement and therefore in scope of manufacturing paradigms.   A false-positive in an IDS is waste Lean should eliminate and evidence of a defective detection routine that 6S should cover. If a flaw in word can compramise a supposedly secure system, then it is not a failure of word, but in the defensive depth of the secured system. If a flaw in word can screw up or lose a document, then it is a failure of word.<br />
Now here’s the rub. What if 6S and Lean, expressed as organization qualities, had only peripheral effect on the success of the business? Toyota’s Lean techniques haven’t made people buy cars in the current down turn.  Lean is about efficiency. Name me one business for whom efficiency isn’t vitally important? 6S is about avoiding mass production mistakes. What business won’t benefit from that at some level except companies that succeed because of bespoke production for whom 6S isn’t that relevant? I don’t mean to undermine these things, they have delivered tremendous savings and efficiencies. But a vibrant market, flush with ready cash is far more important. The ecology of a business is the single biggest contributor to it’s success. If the market demands custom built then mass production won’t help. If the market don’t want what you sell, however good, then the product is a dud.  Looking at the success of previous companies and divining what made them work is very difficult. It is fraught with danger and bad assumptions. The Halo Effect by Rosenzweig (<a href="http://www.amazon.co.uk/Halo-Effect-Business-Delusions-Managers/dp/0743291255" rel="nofollow">http://www.amazon.co.uk/Halo-Effect-Business-Delusions-Managers/dp/0743291255</a>) describes the problems very well and is a must read!   Certainly the level of data needed to prove that these things are in-and-of-themselves recession beaters in today’s ‘noughties-are-the-new-thirties’ world is just not there.<br />
Quality is not free. To describe it as free implies perfection is free, which is demonstrably untrue. It takes practice, honesty, integrity, dedication and energy. Every industry needs that. If you want to sell application security it to C-level executives then prove that the security you deliver is what your customers actually want. But one has to remember from TX Maxx that customers are fickle beasts who’s memory length is inversely proportionate to the depth of their pockets, and aren’t apt to behave in totally rational ways.<br />
Am I right? I don’t know. All I know is that survival is based upon one’s reading of the world and adaptation to that information. More security is not always the right thing. Just ask the blacksmith forging a new sword with a suit of chain-mail on.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

