Social Engineering Blogs

One of the people whose work I have enjoyed of late is Gadi Evron. I find that he and I approach problems and random things very similarly (although he blogs his results far, far more frequently than I do… mine just get saved up for classes, webinars and articles).

So, Gadi posted recently about his disappointment with NLP. It’s not the first time I’ve heard these arguments, and they all come down to a single, fundamental misunderstanding:

What we commonly call “NLP” is not science. Nor is it even scientific.

Most of this confusion comes out of the distinct issue that John Grinder called out in his book Whispering In the Wind. The thing that was originally “NLP” was a project that attempted to model successful people, notice the patterns of language and behavior, and replicate them. (This, Grinder refers to as “NLPmodelling“).

NLPmodelling was not scientific, but at least its principles were sound. Grinder and Bandler went and sat in the room with three strong therapists and learned to “act like” those therapists. They kept doing so until they were able to replicate the behavior. And then they continued to do so until they gained conscious ability to explain how they replicated the behavior.

While none of this was science, at least there was a principle behind it.

Where it all went to H-E-double-hockey-sticks is when they wrote down what they did and tried to explain how they replicated that behavior. This was a fool’s errand in some ways… there are grave epistemological concerns here – it’s beyond difficult to take your own behavior, translate it into conscious understanding and then try to convey it to others in language. It’s the same reason that great baseball players aren’t often good coaches – when you’re really good at something, it can often be difficult to teach others. Grinder once noted that when Bateson reviewed their work, his comment was: “Shoddy Epistemology.” Bateson was accurate, and this is where things started to get wonky.

This is because NLPmodelling is not what most people call “NLP”. When referring to NLP, most people are referring to the things that were written down – the hypothesis explanations that were posed by Grinder , Bandler and their colleagues/followers (e.g. Dilts, the Andreas’, etc.) to explain how they replicated behavior. These are what Grinder calls “NLPapplication“).

Unfortunately, because of the epistemological concerns, NLPapplication is about as scientific as me trying to predict the weather by sticking a wet finger in the air. Because we can hypothesize just about anything. I can observe how certain people act, and then make up any random example of why it must be true. For example, I could tell you that people are a certain way because of the position of the moon and the stars when they were born. How crazy would that be?

So, if NLP isn’t science, what are we to do?

Most people want to throw the baby out with the bath water. I’m a big fan of the original project – let’s look at people who get a particular result, and figure out how they do it.

But if you want to make it science, then turn around and figure out how it works.

Anyone who has looked at NLP has seen the following chart:

(Borrowed from http://completelymental.net/ )

The thing is, anybody who has tried to study whether it works finds that it doesn’t. Yet, many NLP people swear that there’s some efficacy in watching people’s eye patterns and using them to discern how people are thinking.

I was lucky enough to study NLP with Linda Ferguson and Chris Keeler at NLP Canada, and they get it. Linda was the first to point out to me that what Grinder & Bandler probably noticed (unconsciously) was the same set of patterns that Paul Ekman has noticed – we express many feelings and emotions in very small and quick ways with the musculature around our eyes.

So, while eye accessing cues don’t work, we find that paying close attention to that region of the face leads us to a detailed understanding of someone’s emotional state.

This is what happens when you approach a project without solid epistemology – you end up with many of the right behaviors, but the wrong reasons behind them.

And, sometimes, you end up with a whole pile of dogma and “true believers”. But that’s the subject of a different rant.

Until then, realize: NLP is not science. There is some useful background to take the tools and attempt to use them, and, even better, combine them with other, more useful science to figure out how to tie it together.

(As a shameless plug, I’m the one taking the lead on much of the “NLP-like” content at the SE Master Class. I say “NLP-like”, because it won’t be based on either NLPapplication or NLPmodelling. But anyone with an NLP background will find similarities on the things that really work in the real world, without much of the NLP and hypnosis dogma that goes around.)

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.