Wrong Message, Wrong Audience

RafalLos — Tue, 17 Jun 2008 03:26:00 GMT

You're delivering the wrong message, to the wrong audience.

Don't believe me? Let's look at the attendance of workshops and conferences - now look at the message that's being delivered. I'm speaking of course specifically on web application security here. A recent article on Jeremiah Grossman's blog made me think, what do we (as security professionals, and industry "experts", do?) I feel like it's our responsibility to educate and bring the correct message to the people who will really benefit. Interestingly enough, I feel like we're failing to do this to any beneficial degree.

It's one thing to want to deliver software security as a message but an entirely different thing to deliver it to the right people who will actually benefit from the message. I honestly feel like I can't stress this enough.

I think it's wonderful that security is being preached at conferences all over the place, from quality to engineering of software to process management - but the real shortcoming is in who is hearing specifically which message. As a speaker I can tell you that if I deliver the same message to every audience it will be lost more often than it is understood. Tailoring the message is so important. "The message" can be what ever you're delivering on - for me it's mostly how to build better web-based applications resilient to subversion (otherwise known as "hacking") but again - this can be whatever you specifically are trying to convey.

In order to understand how better to deliver a talk with some punch the key is to understand the audience... I've taken my notes from the past several months of conference speaking and will deconstruct the audience for your benefit here...

Management - Of course managers to go conferences, workshops, and talks because every once in a while they feel the need to stay relevant. I can say this without reserve because I was there, and I know for a fact that most managers are so busy trying to make sure their teams are delivering that they often have very little time to do much else - and by the time they look up from their desks technology has passed them by and they are relics. The answer to this is to hit a conference every once in a while and hear what the topics of the day are - a wise choice indeed. The manager as a target audience is very complex but can be simply deconstructed as follows:

Goals: Understand the high-level message being delivered, the current topic and how it applies to their daily life as a steward of the business
Challenges: Unfortunately, being that few managers are really current on technical speak it's very easy to lose a mangement audience in the details, while they want to hear your message don't over-complicate it
Win-Win: Present the topic in a way that can both delivers your point without losing meaning while at the same time making it relevant to the manager's everyday work-life... a tricky thing, I know!

Developers - Developers are a rare gem at conferences where security professionals are speaking, sadly. Developers are keen on making stuff run faster, better, and making their lives less complicated. Notice that I didn't necessarily mention security in the stuff developers are keen on - it's our job as security folks to get them excited about writing secure code and getting them to come to conferences and workshops is a great start but the issue then becomes the way in which we deliver the message. I'll deconstruct developers here:

Goals: Learn the hot new "hacks" and cool code ninja skills which make them more marketable and give them greater ability to innovate and build something truly incredible with their code skills. Developers want to be able to write cool code, faster, and with less effort, period.
Challenges: As I've already pointed out, security doesn't often factor into the mind of a developer. We've been trying for years to change that and to some degree it's working but the percentage of security-conscious developers is still very, very low.
Win-Win: Developers aren't necessarily purposefully ignorant of security, just call it...agnostic. If we can find a way to make writing secure code less painful, and more... developer-centric they'll adopt our principles and everyone wins.

Security Professionals - Preaching to the choir, althoughit's often the choir which hasn't heard the message. I can't tell you how many times I've been in front of a security-oriented group presenting and they're looking at me like I'm a talking Polar Bear... seriously. Security professionals have a hard time keeping up with the technologies they support - it goes with the job - and so hearing something that's a niche piece is often intriguing but we have to find a way to make the message stick! Let's deconstruct a security audience...

Goals: Hear the message, learn the "cool hack" they can take back to their team/manager to feel like they're abreast of security. In security it's all about staying relevant and up-to-date and niche presentations attract security people like flies to honey.
Challenges: Quite simply put - the challenge with preaching to your own audience is that they see things in black and white. Security peers tend to see web application security in a binary fashion; secure or not. This creates a problem some of the time as if we deliver a strong message, say on a new AJAX vulnerabiltiy, the security staff can miss the forest (in this case the 'big picture' of security) for the trees (the specific new "hack") and actually do some reputational damage to themselves within the realm of corporate IT
Win-Win: IF we can provide the right amount of guidance with relevant knowledge we can spur security professionals to make better policies and serve their business better. The goal for us as speakers is to blend technology with intelligence to help mold the perfect security professional - one that is business savvy and security smart

"Engineers" - This is the catch-all category, as far as I'm concerned. These are the other people who don't necessarily fit into the stack above. You've got a mixed bag with this, and it's a challange to make it work, but I'll deconstruct this audience type thus:

Goals: Learn something, take it back and apply it to work - maybe, if it's relevant and applicable. (The secret is since we're talking security it's always applicable)
Challenges: Making security a relevant topic. How do you make web application security relevant to a generic group of IT people? Blend the right amount of technology (so as not to go over anyone's head) with the aspects of IT that make it important to just about everyone - make security "real" with examples from all different sources
Win-Win: The best-case scenario here is to make an impression on someone so that the next time someone says security - they flash back to your talk and recall the message you gave, and as a bonus attempt to apply that (or at least know where to get more information, and point someone there).

There you have it. I hope this has been helpful - so that the next time you're standing there in front of your audience you've got the right mindset and the right goals, challenges, and winning strategy.

Good luck!

Overcomplicating the developer-security relationship

RafalLos — Thu, 05 Jun 2008 20:39:00 GMT

Greetings readers. As I travel and meet with large enterprise customers of HP's I've learned something new that I wanted to share. Maybe it's only obvious to me, and maybe I'm behind the times - but it appears to me that we (and by "we" I mean us security folks) have vastly over-complicated our relationship with developers. Shame on us.

If you don't agree with me, read on. If you already agree, simply nod your head and move on, as I'll be preaching to the choir.

My point is that as the IT Security function we have entirely forgotten what makes a good security process work - simplicity and adoption. We've made our proceses so hard to follow that our adoption rates are abismal and yet we wonder why our application security programs are failing.

Without telling you what tools you should be using (so I don't sound like a sales pitch) here are the things that work more than they fail...

K.I.S.S. - Keep It Simple Security! Why do things need to be complicated to be powerful & effective?

Model your process around the target audience - find out how your developers work and make sure the tools you recommend are inline with that function. If your developers do weekly builds but write code all day long ask yourself if it makes sense to "security check" that code at build time, or from within the IDE as they write it?
Check --> Understand --> Remediate - Your process must be this simple. The security check must be ultra-simple to execute, it must give developers the ability to understand what is wrong (watch the false positives!) and it must provide them with immediate feedback on how to remedy the situation

Use the carrot, not the stick - Forcing people to use something makes you a tyrant; helping them succeed makes you a trusted advisor

Gather metrics
Use metrics to reward those developers who are getting better
Public floggings are a great way to make sure people are too afraid of the results to use your process

Avoid work duplication

Developers love shortcuts; quite simply - help your developers do something right once and then re-use that process/module for the future
Allow others to learn from the lessons of the one.

Just some thoughts... don't take my word for it though. Sit down with your developers. Ask them what would make "security" work for them and you'll hear many of the above things said!

Good luck.

Following the White Rabbit Blog : educating developers

Wrong Message, Wrong Audience

Overcomplicating the developer-security relationship