When you ask developers what they think of security training, they will likely go into the situation without much enthusiasm as security training can be monotonous if it isn't thoughtful and mindful of the needs of developers.
Developer security training is important because developers are the ones writing the code in the first place. However, most security training leaves developers bored and uninterested. This means they will retain nothing and they won’t understand security enough to apply it in their work. If your developers don’t understand security then your code cannot be secure; you wouldn’t want to walk on a bridge built by an architect who didn’t understand bridge safety.
Security breaches cost companies millions of dollars every year. The average cost of a data breach is $3.92 million. But risk isn’t the only driver. Compliance requires that you train your developers on a regular basis. Unfortunately, many companies only do a “security awareness” training or program once a year to check the box.
Mature organizations know that software can’t be considered high quality if it’s not made as secure as possible. Software testing, scanning, and penetration testing aren’t enough to ensure this. Developers must know how to write secure software.
How should developers learn?
Traditionally, corporate training happens in classrooms where someone is lecturing you about a topic. There’s not much difference between traditional corporate training and a college classroom. Your teacher gets up in front of the classroom and speaks to you and you’re expected to learn passively while you listen.
Another common technique is the video “e-learning” module. Instead of a teacher lecturing you from the front of a room, the teacher does it through the computer. Complete with slides and monotone narration. This is not the best way to teach developers. Developers can barely stay awake when taught this way.
Hands-on or hands-off
College educators are now learning that lectures aren’t effective. A study found that college students in lecture classes were 1.5 times more likely to fail then those in classes that use more stimulating learning math methods.
It also showed approaches that turn the students into active participants instead of passive learners reduced failure rates and boosted scores on exams by a large margin. Translation: lecturing doesn’t work. Active participation does.
The same is true for adults and developers when teaching them how to develop secure code. Videos and slides are great complementary material to help developers. However, more is needed if you want developers to apply what they learn every day. Developers must be active participants in the training. They need to see vulnerable code, exploit it, and learn how to fix it by actually fixing it. But are companies actually teaching developers this way?
Hands-on works
Once every year Facebook runs an event called Hacktober. For the month of October, Facebook has several activities geared toward increasing security knowledge across the company. There are interactive workshops, capture-the-flag competitions, and educational sessions with the security team. It helps developers to know who the security team is and what they do. It also provides a fun platform for them to build their skills in defending and exploiting applications.
Etsy has taken the lead in getting developers to care about security. Etsy rotates its developers into the security team for a certain amount of time. Junior developers are there for a week when they first join the company. Senior developers can spend up to a month with the security team each year. This allows the developers to get hands-on experience from within the security team. They can learn much more about security by living the day-to-day life of an application security specialist.
Many companies now see the need for active participation in security awareness programs and security training. Even the government is getting on board. The bottom line is: you can’t expect developers to retain security training if that training involves simply talking to them.
How you can do hands-on
What are some methods that you can use to give your developers hands-on training? An effective way is to use capture the flag games to give your developers a fun and engaging way to learn. Capture the flag programs pit teams of developers against each other, one that is trying to break into the system and another trying to defend it. There are usually point systems to help developers to outshine their competition and learn in the process. Facebook has open-sourced the platform that they use to build their capture the flag exercises. Companies can now use what Facebook has done as a foundation for their own CTF events and activities.
Another way you can teach your developers is to start an internal bug bounty program. A bug bounty program encourages developers to continually find bugs and to report them when they do find them. This gives them the hands-on training on a continual basis of how to find security issues. If they can find vulnerabilities on somebody else’s application, they can find it on their own.
Rotations into the security team can also be helpful. Give developers a chance to see what the day-to-day life of the security specialist is. Another very effective way of training a developer is with a hands-on development training platform. It’s important for developers to exploit and fix bugs in the languages that they use every day.
Security Labs is such a platform. Our platform guides developers through hands-on lab exercises so that they can learn how to fix vulnerabilities in the language is that they actually use. This is not training with boring videos, presentation slides, or a teacher standing in front of a room lecturing. This is training that sticks and helps developers to notice security issues while they’re developing for you.
Boring is dangerous
Boring training simply doesn’t stick. There’s a big difference between sitting in a Computer Science classroom and sitting at a computer doing real development work for a company. Similarly, there is a big difference in sitting in a security training classroom and actually finding and fixing security bugs in your development frameworks.
Use hands-on techniques to help developers gain an appreciation for security concepts and how to apply them. “Gamify” the learning process by creating some internal team competition. Give points and let your teams compete on a leaderboard. Give out prizes for the best performers.
It will be engaging. And it will stick with them too. Step out of the classroom and into real life.
Excite your developers, don’t bore them.