Damn these infernal mornings.

Click here to subscribe to Liquidmatrix Security Digest!

And now, the news…

1. 1st Source Bank replacing debit cards after security breach | Network World
2. Microsoft Warns Of Bug In Apple’s Safari | CRN
3. Going Back to Basics To Fight Botnets | Top Tech News
4. EU security agency warns over insecure printing | The Register
5. Information at thieves’ fingertips | Times Union
6. McAfee Names The Most Dangerous Domains | Information Week
7. IBM Complimentary Security Health Scan | Bitpipe
8. ‘Hacker’ left child porn images on computer, lawyer insists | The Toronto Star

Tags: News, Daily Links, Security Blog, Information Security, Security News

Have you ever sat in a corporate training? Some are good, some are bad, but did you ever say, “man I can’t wait for training today.” What about mandatory training? What about mandatory training in a subject that you really don’t think is your area? What if you had to do it every year, and got harassed if you didn’t do it? What if you were, say, an audio engineer and were dragged into a security class?

I ran the SDL training program at Microsoft for a long time, and developed and taught a big chunk of the training. I spent hundreds of hours in front of thousands of developers, testers, and program managers. I got some really good reviews (and a few bad ones) on the classes I offered. And I tried to do a lot of things to try to make the trainings interesting. I handed out dozens of fresh peaches in an early class on fuzz testing, for example.  The room smelled really nice after that, and there are probably still a few people around Microsoft who think of fuzz testing when they see a peach.

But even on my best day, I was under no illusion that the majority of the audience was excited to be there, and I was certain that they weren’t going to go back to their offices and spend weeks applying the lessons from the class, setting aside other things that are causing present and immediate problems in favor of something that is far off into the future.

You have to work at getting people’s attention – especially as it relates to security and privacy. From time to time, I would see people reading their mail in class, and I would point to them and ask them a question. That did not endear me to the audience as much as the peaches, but embarrassment is always fresh and in season.  J

One student wrote of one of my classes, “the basics for secure design - could be replaced by non-anonymous site-wide exam with open material.”  He was not alone, I assure you.

Is that an indication that our training, or any training, is pointless? Hardly, but training alone is not a change agent.

Richard Derwent Cooke wrote,   “It is a first principle of Change Management that people will act in what they perceive as being their best interests.”

At best, training can provide people with insight into what they need to do to solve a security problem if they believe that solving that security problem is in their best interests.

To be effective, training needs to happen in an environment:

·         Where expectations are clearly set (the SDL sets specific minimum requirements).

·         People have appropriate incentives and consequences (security is a great career path at Microsoft, and nobody wants to be the one holding up a ship schedule for failure to meet a security requirement).

·         Where tools and resources to accomplish the goals are available (we build a whole variety of tools that map to the SDL requirements).

·         Where management models the behavior (recall the original BillG TWC memo).

·         Where the environment reflects and supports the values presented in the training (apparent in everything Microsoft does).

Don’t make the mistake of thinking that a bunch of training, even really high quality training done periodically, will result in actual behavior change. It won’t. You have to build an environment where people perceive solving security problems as being in their best interests. You have to make security their problem – not in the sense of passing the buck, but in the sense of changing their behavior so they will bring security problems to you.

To illustrate further, I’ll cite two examples. First, fuzz testing. Fuzz testing has been a success story here at Microsoft. Tools arise spontaneously to solve new fuzzing challenges, written by people who believe the challenges are their challenges. There are people who feel ownership for our fuzzing strategy and on-going research and science, there are specific goals and requirements, we have training (remember the peaches?), and internally developed fuzzers have won prestigious awards within the company, handed out by members of the executive staff, and all of this gets revisited periodically as part of the SDL.

 By contrast, I’ll choose a less successful area – defect estimation. On my own volition, I created (based mostly on some excellent material from Microsoft Research) and taught a class called “Defect Estimation and Management” and added it to the SDL curriculum. Microsoft is a great place to work in that regard. It was pretty close to the best-reviewed class I taught. But, we have not yet been able to establish a set of tools to estimate security defect density effectively, and establish a fair set of expectations, incentives, and consequences, or even  decide what we should do if we had the data. We discovered some things, though. For example, based on what I observed (which should not be construed as rigorous research), it does not appear as if the density of general defects correlates closely with the density of security defects.  And Microsoft Research found higher code coverage in testing correlates with higher bug rates in the field.

And so even though people like the idea of defect estimation, and we’ve got some interesting and surprising data, we’ve not yet been successful in changing people’s behavior.  Generally speaking, an individual test manager does not feel that establishing a high quality estimate of their defect density is in his or her best interests, as compared to, say, improving the time in which an established series of tests can be performed .  

We need to build an environment that has the tools, training, rewards and incentives, and expectations and consequences to change people’s behavior. Not that we’re not trying. But training won’t solve it alone, nor would tools, trophies, rants, testing, code review, or some edict from on high. The SDL is as much about changing the culture and influencing the behavior of individual engineers as it is anything else.

I’m convinced that Microsoft’s SDL process works because it addresses the end-to-end problem - from training through servicing, and provides a complete environment where people feel ownership of their part of the security problem and have the resources to solve it.

So the next time you find yourself sitting in some mandatory training, remember the lessons of the SDL (and most of the research on human performance management): training alone won’t cut it. If you want real behavior change, there have to be things outside the lecture room to influence people to change their behavior.

Don’t get me wrong.  I greatly admire the work Mike does and wish he and his book had been around when I started out as a CISO.  Would have saved me significant pain and suffering.  On the other hand, if I’d had Mike’s P-CSO I might have become complacent and ended up believing that’s all there was to being a CISO.  Not that I think Mike is advocating complacency — he’s not.  I also don’t think he discounts risk analysis concepts.  He’s simply focused on helping that component of our profession who’s just getting started or who faces other practical constraints in dealing with our very complex problem space.  His is a necessary and highly valuable contribution, and he provides it in an entertaining way that’s too rare.

Let me set this discussion in a medical analogy context.  If I was in the middle of nowhere or didn’t have the resources for a physician, then a medic who’s skilled in lifesaving basics would do just fine.  However, if the situation called for a deeper understanding of the complex, sometime subtle health considerations, then I’d prefer a physician.  Someone who didn’t say;  “Boy, this anatomy and physiology stuff is complicated.  I’m just going to stick with ‘The hip bone is connected to the back bone…’”   My physician may, of course, choose to follow a pragmatic, commonly-used course of treatment, but they’d be able to do so with a deeper understanding of the problem space, greater (but not perfect) certainty that the course of treatment would work, and a better ability to explain to me, the patient, why I had to swallow this bitter pill, undergo the knife, or have this long tube snaked into one of my orifices.  

Yes, I realize that physicians sometimes get it wrong, sometimes get wrapped up in fancy and even unnecessary procedures, and can drive up costs.  That’s just as true as what can happen at the other end of the spectrum — the shaman who operates entirely by superstition, faith, FUD, and intuition.  The point is, there’s absolutely a need for both medics and physicians (and levels in between).  We, as professionals, can choose where we want to be within that continuum.  With this in mind, a few things to consider are:

• In the heat of battle, when resources are limited, or when it just makes sense, physicians always have the option of behaving as medics and sticking with the bare essentials (the reverse isn’t true).  In fact, the best physicians I’ve encountered are pragmatic in their approach but have the deeper knowledge to leverage when need arises
• Medics might effectively deal with 80+% of our problems, but that remaining ~20% can be critical 
• A person can start out as a medic and then become a physician later, as need and resources dictate  
• Physicians tend to be paid more

Bottom line — knowledge and understanding are never a bad thing, but it requires extra effort to acquire them.  And, as Mike points out, the simple approach is often good enough and may be all we can hope for given our individual circumstances.  For myself though, I prefer a deeper understanding of our complex problem space.  I want to be able to answer the hard questions about why and how.  But that’s just me.

BTW - I was amused at Mike’s characterization of risk analysis as Black Magic, as this phrase would also have been used in the past to describe medical and scientific concepts/practices we take for granted today.