Published on
This post was written by Chris Romeo during his tenure at Security Journey.
You would think that there is not a single developer on earth who has avoided the impact of a data breach or security vulnerability. That should cause every one of them to focus like a laser on security. Unfortunately, this is just not the case. Everyone, developers included, has become numb to data breaches.
This numbness can be overcome when a development team gets fired up for security. Perhaps they receive a security spark from their executive management or a customer. Or, in the worst case, they experience a security vulnerability or breach, and everyone finds security religion.
But what about the opposite end of the spectrum, when a development team looks you in the eye and says, “We do not care about security.” That is a difficult challenge to overcome, because their reasoning has some merit. They say things such as, “Security is a cost that we cannot afford to pay. We must ship the next release, and the ship date is non-negotiable.” This team does not care where the directive came from. “Tell the CEO we said that we must ship the release because we promised the customer.” They have a point, but do they have a real excuse?
Waking developers up to their reality
This challenge is not the end of the world. All people have some amount of reasonableness inside, no matter how far down it is buried. We just have to burrow down and connect with them and cause the security light bulb to go on for them. I’ve had this experience numerous times during my career as a security evangelist. I’ll go in to work with a team that says they don’t do security, or don’t have time, or any of lots of different excuses.
I’ll begin to work with them, teaching and mentoring, and slowly pointing out flaws in their application. I teach them the process that I use to uncover those flaws. The security light bulb goes on when they suddenly realize the magnitude of the threat and the inherent risk in the development choices they make. From that point forward, they are changed, and they no longer rail against security but become staunch supporters of all things security.
To connect with the development team that puts their hand in your face, here are four specific things you can do to sway them to the security cause.
1. Start with why security matters
Simon Sinek has a great book titled Start with Why. As folks with a passion for security, we all too often jump into teaching security by focusing on the bits and bytes of input validation and output encoding. All that the average developer with little security experience hears is that we want them to do more work with the same amount of time they had before this “security thing” became popular.
The way to combat this attitude is to explain the “why of security.” Why do they need to care? What are the ramifications if they choose not to? I like to use examples from everyday life. What happens to an air-traffic control system when security is not a priority? How much effort do you think the company that manages the data for the office of your child's doctor should put into securing their applications? Your kid’s personal health information is worth something, right?
Draw back to why developers need to care, and that will connect with some of them. Land the plane on this conversation by circling around to the customer requirements for security and the impact to the customer if data is breached from your system.
2. Determine what motivates the team
Everyone is motivated by something: money, power, fame, or influence. You need to determine what motivates this development team. Is it a chance to have a party at a restaurant on a Friday night (a team-building event)? Is it cold hard cash in their pockets? Some teams love custom T-shirts. Use whatever motivating factors influence this team to entice them to learn about security
.Motivation via rewards and recognition is a connecting point with any team. Once you discover their motivation, build a learning program to reward the team for hitting milestones. Perhaps one milestone is having everyone watch an initial set of video modules together over lunch (provided by the company), one per week, and then participating in a discussion for 30 minutes. At the conclusion of the six weeks, there is a special team-building event to celebrate the fact that all of the team members increased their knowledge.
If your executive management team is pinching pennies at the moment and challenges you that this expense is not required, explain that a single breach of your systems will cost a thousand times more than a lunchtime security learning series. You must partner with your executive management team. They control the pursestrings. Ensure that management is on board with the motivational plan and will fund it. If management doesn’t support the concept of securing the product to improve the customer experience, it will be difficult to get the team on board.
Do not try to achieve better security by having management pass down a security mandate. Mandates breed compliance, and compliance is not security. Compliance is checking a box. True security requires changing how the humans approach securing the product.
3. Throw in a bit of custom gamification
Gamification is applying to other parts of life the principles that make video games successful and addictive. Set up a series of events for your development team to do and choose a theme for the event.
Theme, you say? This isn’t college, and no, I’m not suggesting a toga party (unless that works at your company.) Talk to members of the development team and find out what they like to do or what they watch on television. Are they Game of Thrones fans? Uber did a whole security awareness campaign using Game of Thrones as the theme. It created teams named after the houses of GoT and awarded points for good security hygiene. Connect with a topic that the team is into, and layer security on top of it to connect with them.
Gamification adds fun into the mix, and who doesn’t like to have fun at work? Gamification connects fun with security.
4. Begin with the foundational lessons
To win this team over from the dark side, you need to begin to familiarize them with the foundational lessons of application security. After you have them kicking the tires because you’ve laid out the why, determined their motivation, and created a game-based experience, teach them the basic vocabulary of application security: attack, threat, exploit, and vulnerability.
As the team begins to learn the basics, they will pay more attention to the security news that they hear every day. Next time they hear of a SQL injection vulnerability that resulted in a data breach, they will be more likely to want to learn additional details about SQLi.
Success in reaching any development group is a programmatic affair. Start with the why, explore motivation, make it a game, and then teach them the foundational lessons. You’ll get to the end of step four, and you’ll realize you’ve connected with them, because you took a step to walk a mile in their shoes.
Read more from:
Application Security