We, as security professionals, have to raise our game. We have to be respectful and helpful. We have to know our audience and speak their language. If we are seen as the guys who will pounce on a mistake and publically humiliate the organization who makes a mistake, we will only make enemies among those we want to help. If we take the attitude of “every mistake is a catastrophy,” we will be ignored by management who will hear us saying “the sky is falling” and they will look out their window and see that the sky very plainly is not falling.
I will let Hunt’s own words express it best (modified slightly by me).
there [is] a bit of an opportunity here – an education opportunity for [security people] who like to learn from anti-patterns, i.e. seeing how those who have gone before them have done it wrong
Over the weekend, a whole storm spun up over Tesco’s web site security. I made a bit of a storify of it. They store passwords in the clear, they violate a bunch of SSL best practices, etc. Troy Hunt gets credit for the seminal tweet. Prompted by the flurry of interest, Hunt goes on to do a bit of investigating and blogging. What I think is noteworthy about his blog is the tone of voice. It undermines the (true and important) message and it represents a failure I think is common among security people. My favourite tweet was from matthewhughes: when he says “I think tone is less important than being right. And Troy was spot-on, IMHO.” That is exactly what I mean by “security tone deafness."As a security consultant, I know we have an image problem when talking to enterprises. How many security people have bragged about “pwning” this site or that site? How often do professionals deliver their results like they’re lecturing a child? The tone comes across like “You idiot! How do you not know something this incredibly simple?”
Having a section called “lessons for developers everywhere” misses the mark on the Tesco situation and it is a bit of hubris that does not win us friends among developers everywhere. It does not make the audience feel like the speaker/writer knows something about them and what they go through. Think of whatever negative emotions you’re feeling right now as I take it upon myself to lecture security people everywhere. As if I know something about security that all security people need to hear. Now assume that developers feel the same reaction when security people lecture them on developing software. How do we fix that?
It is also wrong to lay the blame at the feet of the developers. Developers don’t make these sorts of choices in large organizations like Tesco. There are departments like operations, development, project management, etc. There are processes. It would be foolhardy to change the password system without doing a full set of testing on the site. So if that full testing takes six weeks to do, then these are non-trivial requests. They cost money, they impact all the other priorities of the project, and they delay features that are important. They are not choices developers are allowed to make unilaterally even if they know how. Some of the lessons (e.g., web server configs) are an operations issue. Other lessons (let people use any character in their passwords), are developer issues. They might be subject to policy, discussion, or compatibility with multiple back-end systems. For many organizations, the operations staff might even be outsourced, requiring the main owner like Tesco to force a change through their supplier"not a quick process.
We, as security professionals, have to eliminate this tone of voice and be constructive. In places where Hunt recommends things like .Net upgrades or ASafaWeb, he is on the right path. When he makes absolute statements regardless of context, he is falling prone to security tone deafness. The first 5 “lessons” use the words “always” and “never”, which suggests that security professionals can make security decisions in a vacuum, irrespective of context. That is not true, and it serves to disconnect us from organizations who make risk-based decisions that include their business context and the cost/benefit of security choices.