Six Sigma and App Security
March 20, 2009
From a note that Hoff tweeted, I ended up reading Jeremiah’s awesome new post in which he asked the following question:
“How do you achieve quick wins in Web Application Security, rooted in software, with measurable results that CIOs would appreciate? ”
I started a thread on twitter with my answer, but that’s not the format for reasoned discourse and detailed thinking. So, I decided to write about my thoughts a little more in detail here.
The answer is simple: You don’t.
Jeremiah laid out most of the reasons in his post, but it comes down to one thing: an SDL improvement effort is a multi-faceted, process-based set of changes that lead to a long-term process that creates security through up-front consideration, not through solving one-off tactical issues.
In that way, the effort that Jeremiah lays out is exactly the same as that faced by the Quality proponents and Deming followers in the 80s. Everyone “knew” that quality was important, but nobody could ever justify the up-front costs of redesigning an entire process to create that kind of quality.
In short, there were no short-term wins.
Yet, today, almost every large corporation has implemented some form of Six Sigma/Lean/TQM program at some point.
The point I was making on twitter was that, if there’s a model to follow to find the way to make application security palatable to the C-suite, it’s the adoption model of Six Sigma.
I see three key points to the adoption of quality as a movement.
Business Pain without a forseeable end
The main driver behind the quality movements of the late 80s and early 90s was the pain that most organizations were feeling. The economic recovery of the 80s lead to a strong competitive environment, with extra pain coming from overseas competition. In the case of the auto industry, it was Japan. For other orgs, the pain came from other offshore and domestic competitors. And as the economy slowed in the late 80s/early 90s recession, many of these organizations looked for a sustainable competitive advantage to give them an opportunity to survive when others in their space couldn’t.
The economy is leading us to a similar state today. Businesses are looking for an advantage as the economy turns down. (Note that I don’t believe that application security leads to a sustainable competitive advantage in the same way that Lean and 6S do. I’m just making a parallel between the conditions).
Examples of Success
The most important factor in the adoption of quality processes was the very public example of success put forward by Honeywell, Motorola and GE. From Wikipedia:
“Other early adopters of Six Sigma who achieved well-publicized success include Honeywell (previously known as AlliedSignal) and General Electric, where the method was introduced by Jack Welch.[8] By the late 1990s, about two-thirds of the Fortune 500 organizations had begun Six Sigma initiatives with the aim of reducing costs and improving quality.”
Because these organizations put forward incredibly public accounts of their success, it was easy for other C-level executives to embrace the potential of the initiatives. While every leader wants to believe that they’re an individual, the top levels of business are very much a CYA culture – only the success of one’s peers allows one to take the risk.
This lead to…
Quality is Free
As these successes built, documentation started to build the belief in this type of program. This eventually lead to the mantra that “Quality is Free” – the idea that a successfully implemented quality program pays for itself in the long-term, regardless of the short-term cost/pain associated with the implementation.
My point to Jeremiah is that the Application Security community is living without the latter two of these points – we have no examples (save perhaps Microsoft) that show that a consistent focus on process-oriented security is successful. And we have no data that backs up the long-term cost benefit of the initiative.
In a situation where the task requires long-term process reorientation, short term wins aren’t possible. We need to follow the model of the adoption of Six Sigma: We need to court those forward-thinking, Jack Welch-type CIOs who are willing to make this happen, and then have them make their successes public.
Only then will we see a widespread adoption of security-focused SDL reengineering initiatives.
Comments
5 Responses to “Six Sigma and App Security”
Got something to say?
This is indeed a rich topic for debate. For the sake of argument I’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.
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’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’re ever going to have mass-market penetration, we need those early adopters in the same way that Six Sigma needed GE & Applied Signal and Lean needed Toyota. We need to use the quality movement as a metaphor and a roadmap to organizational adoption.
I haven’t seen that yet, which isn’t going to make it something that CIOs recognize as valuable.
So what we really need is a killer app that by it’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’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’s pull methodology for creating self evidencing compliance controls – not exactly sexy, but necessary none the less.
It sounds like you’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’s 2 ways to frame the conversation 1) You’re going to make X amount of money or 2) You’re going to not lose Y amount of money.
The problem with option 1 is unless you’re going to build and sell a solution to secure you’re application security, you’re not going to make money on it. It’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’s a lot like insurance. Everyone hates it until you or someone close to you needs it, then you’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 “we saved umpteen million dollars” moment that gets shared with the world?
[...] 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 – [...]