But does just knowing about it change their behavior? No, it does not!
The reason is that these "invisible" negative effects do not influence their living, the integrity of their reality is intact until it is too late and the disease dramatically decrease the quality of their life.
Only a few people are clever and strong enough to reflect about their bad behaviors and change them. I assume more people change their bad habits as soon as they see what happens to their body. Seeing means measuring the cardiovascular levels, taking x-ray pictures of organs, making chemical analysis of body liquids and tissue and so on.
I see a strong analogy here to software development and security.
Developers and project-managers often do not have security in mind, or do not have the technical background and daily practice to make the resulting product a nightmare for penetration-testers and hackers. (How often do you read this already?)
Let's not stress this doctor vs. patient analogy too far. This blog entry is not about good vs. bad or dumb vs. clever... it's about the experience I made and psychology.
First of all, measurement (of the right things) is the key to success! You do not have to create a bulletproof plan, just some goals, continue measurement, and adapt your plan (Hello agile development/management!).
I hold three talks/workshops in 2010, every talk has the same topic: "secure design and development" and I got the same result: Code quality did not increase! The number of potential security bugs per 1000 "physical" LOC (Hits/KSLOC) stayed the same or even increased.
Based on the responses from my audience I experimented with the content and with the methodology. The first workshop was very long and mostly theoretical with threat models, potential problems in Rails, risk assessment, showing some tools (which gets the most attention, because it potentially helped solving their problems).
The second one was much more practical, I had shown real examples from the in-house software projects, real attacks and presenting some tools. The session was much shorter and caused more attention by the developers and a bit more attention by the technical managers (Still, tools caused the the most attention). And the last one... the last one was a wake-up call, less technical, analogies and examples, cost of security updates (Attention!) and I hit the target.
Result: The first talk was a waste of time, my statistics had shown no decrease in the potential vulnerabilities, the second one also had no affect on quality but the awareness and communication (developers) increased, and the third talk... well the code quality did not increase but awareness and maybe acceptance in the upper food chain increased.
Retrospectively I can say I should have done the talks/workshops in reverse order but when I started is was a "fire-fighter job" and I had no time for a real plan.
Code quality is still a critical issue and therefore I took the next, more aggressive step by sending the (cleaned-up) results of my code scanner to the developers mailing list. And at least one team responded to it and we reduced the number of potential security problems and false positives to a minimum within just two weeks. In the meanwhile all teams responded in some way and I hope code fixing will start soon.
On balance:
- If you want to increase awareness, invite the right people and omit technical details, speak the language of the audience, use numbers (costs) and statistics, use analogies instead of theoretical information. Melt realities by creating feelings and concernment! (The last point is not easy to do of course.)
- If you want to increase code quality, use tools that directly show the problematic code with a description and help fixing it! Don't create too much confusion and don't steal the developer's time.
No comments:
Post a Comment