This is the fifth post in SAFECode’s Month of Champions series on building and sustaining a successful Security Champions program.
- Part One: Start 2019 Strong: Join SAFECode for Our Month of Champions
- Part Two: Building Secure Software: It Takes a Champion
- Part Three: Putting a Face to Software SCs
- Part Four: How to Build an Effective Security Champions Program
By Tania Ward, Dell with Altaz Valani, Security Compass
Sometimes, despite the best intentions, Security Champion (SC) programs can run into trouble. Often, when launching a new initiative, it takes a bit of trial and error to get things right. Many SAFECode members have already learned some of these lessons in the course of our own program design and implementation, and in an effort to help others avoid some pain, we thought it would be helpful to share some common characteristics of an SC Program that’s in trouble. Here are a few things to watch out for:
- Diminishing resources: When resources start to go down, you know your program has been deprioritized. Like the game of Snakes and Ladders, go back to the start and reassess your foundation.
- Over-reliance on Computer-Based Training (CBT): With so much out there, it’s easy to get caught in the whirlwind of education and think you are doing enough by providing links to various online resources. But our collective experiences have shown CBT is often not adequate on its own. Instead, Consider a blended approach to training. Add instructor-led training and mentoring to the mix, and offer content targeted both at awareness-building and skills-building, as well as training courses focused on promoting specific behavioral changes. Providing the right mix of training – both in terms of content and format – keeps the program fresh and interesting and supports growth in all areas of security culture-building. And If you don’t see any improvement, verify that your training program is adequately focused on proper teaching, understanding, and retention.
- Lack of communications: If you’re not fully committed to executing on your SC program, then don’t expect others to be fully committed.
- Security is seen as a feature and not as a process: When engineering teams view security as a feature it is easily deprioritized. Security should be seen for what it is: a process that is designed to build security in (Security by Design) with the end goal of improving the overall quality of your product.
- Bad-cop perception: Driving security through “FUD” and/or as a compliance requirement will only lead engineering teams to view it negatively. Speak their native language and be an integral part of their team.
- Lack of accountability: If the team thinks security is not achievable, challenges should be discussed openly as opposed to simply worked around.
Recognizing the symptoms of program trouble early will help you to diagnose the problem and fix them quickly.
Building a security culture through an SC program is built on aligning all aspects of engineering from the start. Behind every security-aware engineering team stands a SC who has paved the way. So, who’s paving the way for our SCs? The next post in our series will focus on how to roll out an SC program and how to keep SCs engaged.