The Ballad Of The Security Champion

In the Security Champion Program Success Guide blog, I invite industry professionals to offer their opinions, thoughts, experiences, and viewpoints about Security Champion programs in order to expand our collective knowledge and encourage a healthy conversation.  In this post, Izar Tarandach offers a reality check about Security Champion programs that is full of lessons to help you avoid pitfalls.  Enjoy! — Dustin Lehr

Information Security practitioners (are we calling ourselves “operators” yet?) absolutely love military analogies and terms. We borrow extensively from the jargon and the culture – plus, we are fortunate to count among us many veterans from all nationalities and service branches. One of the terms a lot of people involved with Security culture in organizations, in particular application security, use constantly is “Force Multiplier”.

Brady Moore expands on the concept of “Force Multiplier” in this article as applied by the US Army Green Berets special forces operators in some detail, but this is the gist of the idea: a small, well trained, well supplied cadre of highly specialized operators is able to train locals in their own environment, with their own equipment, in their own language, with their own leadership, with great effect in enabling a resistance movement.

Sounds familiar? If you ever considered Security Champions, it should. The idea that a small, well trained, well supplied cadre of operators is able to train local developers in their own environment, with their own culture, in their own language under their own leadership is supposed to have great effect in enabling a security program. 

That is an idea that sounds great and almost simple (as much as anything in Security may be called simple…), but in my experience it is easier wished than done. When it comes to Security Champions I am what you could safely call a “naysayer”, a “contrarian”. Or a “kvetcher”. Some even go as far as calling me a realist. You see, I don’t believe in the heroic Security Champion acting as a de-facto local Security Team embedded in a development team:

1. The Security Champion is more often than not “voluntold” to take the position. It doesn’t “come from within”. It is not a calling. It is more like a calling out.
2. The Security Champion now gets the security responsibility for all members of the team, plus their own pre-existing workload
3. There is usually little or no incentive, material or otherwise, to become a Security Champion. Fame and fortune do not follow, unless you move into a Security full-time position, where small amounts of fortune may materialize, if you’re very lucky. 
4. The other components of the team eventually develop a less-than relationship with the Security Champion – who is then expected to either fix all security issues themselves, or “get off our back with your security thing”
5. There is a lot of stress around the expectations from a Security Champion – do they now have to know all that’s going on in the team so they can apply the security point of view? Do they need to go to special, frequent training? Are they now a mini-boss demanding that the other developers comply and attend to security matters?
6. Security Champions are singled out for special training. But by definition they serve heterogeneous teams – otherwise the Security Team itself would be able to deal with all development teams in the same manner, without the need for in-place specialization – and that leads to either generalized training (that every developer should get) or highly specialized training (that developers in that particular stack should get).

These have all been situations I observed around Security Champion programs in the past, in a variety of different organizations and cultures. Over time, I’ve developed my very own Security Champion Achievement Maturity Model (SCAMM). In it I measure the overall posture of your typical developer on their journey over Security, and the impact they may have on their team:

It may sound like I am putting this down in jest, but we can learn a lot from pondering these progress stages and what defines them vis-a-vis Security Champions capabilities and the constraints they operate under. 

Even if we think in terms of a “train the trainer” architecture (Green Berets again!) where the Security Champion is expected to extend their special training to the developers, rather than do things themselves, we are being over optimistic – we expect that someone with a small amount of training will be able to convert that experience into the ability of training others to be effective. What follows is either the illusion of “just enough training” or a game of broken telephone. 

The fact is, when someone is trained up to the level where they can effectively ask the right security-related questions and provide correct security-related answers, they should be considering if a career in Security is available. The Security Champion has just self-ejected from the development team and became a full-fledged Security Person.. They can now shed their obligations as members of the team and enjoy the special access to the Super Secret Security Club (we have cookies!), as they have finally proven able to effectively perform the Secret Handshake.

Well, thanks, Izar, now what do I do with my Security Champion program?

My suggestion is, you reframe it. You don’t have Security Champions now. You have Security Liaisons.

The role of the Security Liaison is much more limited, by design, than the Security Champion’s. But at the same time, it is much better defined. 

The expectation is that the Security Liaison be a fixed contact point for the Security team to ask questions – in a constantly changing environment, the Security team has also to deal with communications, and go figure out who this week is leading team A, and when their status meetings are, and who owns feature Z among their developers? Well, someone in the team who is more-or-less well positioned to know those things (but not necessarily a manager, or a higher ranking member of the team) can help figure those questions out. The Security team all of a sudden only needs one person, one stationary point, to be able to field and answer questions about that whole team. Security Liaisons also participate, as they can, as an interested party, in a totally optional manner, in the discussions fueled by the questions from the previous item. But hey, no hard requirements, you do you and if security interests you, that’s great. They have the same security training expectations you would have from any other developer. List the Security Liaisons in a public place like an internal wiki or something, and make sure the Liaisons themselves keep the page up to date. 

Communicate with the teams, specially in probing initial questions, via the Liaisons. Let them do the internal legwork to help find the answers, but don’t make them responsible for them. 

IF, over time, your Security Liaisons want to do more and have more responsibility, let it flow naturally. If they don’t, don’t push it. Keep it low touch, low expectations (in volume, not in quality!).

But let’s say that Security Liaisons also won’t work for you. Am I saying that there’s no way your Security Champion program will work, and that it is doomed to be one more failed initiative? Well, no. What I am inviting you to do is rethink your own expectations from a Security Champion.

Don’t inundate them with requests. Don’t overwhelm them with responsibility and expectations. Understand that the job they were hired to do is development, or program or product management, and they are not security professionals.

Consider how you will reward your Champions/Liaisons. One more bluetooth speaker, or their name on a top-3 point achievement list? I’d say you probably want to rethink that. 

Honor their commitment by honoring their time and giving them only the training you think they actually need, and most important of all, support them! Be there for your Champions/Liaisons, help them and they will, to the extent they can, help you.

And be happy when they ask to join the Security Team. They know where the product skeletons are buried and where the possible mitigations would work best, who knows what and how the developer culture works. They know the levers to push to get the most effective results, and that’s invaluable.

— Izar Tarandach

Want to share your own viewpoint or case study about security champions? Contact me on LinkedIn and let’s chat! — Dustin Lehr