In order to make sure that a security training is effective you need more than just a hired coach.
In that case, how to choose a well designed security training program before you make decision and pay for its execution in your company? Let’s learn more about the most vital aspects of such programs from an interview with and expert: CyberForces CEO and Chief Security Strategist, Dawid Bałut.
In your opinion, what are the characteristics of effective developer training?
I believe that effective developer training must be entertaining and relevant. It must be entertaining because they expect engineers to devote their time in learning something they won’t be directly rewarded for. Software engineers like to learn new skills so they can then use it in the workplace and get compensated accordingly, while in case of quality assurance skills, it’s not directly tied to their compensation.
Engineers look into the future, meaning that even if they’re being rewarded internally by their current employer, they know not all companies reward for such a skill set and they prefer to learn new programming libraries, frameworks or languages to become more employable. That’s why security training can not be boring. People must know that besides the skills they’re going to acquire to build better products and to have skills that in the future more companies may appreciate; they are going to have a blast playing with a training platform. So entertainment really matters, it’s our leverage helping us convince software engineers try out the platform. And if it’s good enough, they’ll stick to it like to any other game. So if you gamify the security training, you’re increasing your chances of it being successful.
Security training must also be relevant, meaning that engineers must know that they’re acquiring knowledge that matters. They don’t want to learn theory which they know will quickly forgot, they don’t want raw facts about the whole security industry. They want knowledge and practical know-how on how to build more secure products using technologies they’re developing on a daily basis.
There are other properties of effective training such as frequency of it, internal reward system in the company, availability of the training, difficulty and many more, but the two pointed out above matter the most in my experience.
How to measure effectiveness of a developer training?
We can measure effectiveness of a developer training. One of the three most popular ways of doing that is checking if the platform is used by validating the access logs and the dashboards of each employee to check if they’re making progress in the platform. Second one is checking if the number of bugs introduced in the new code decreases to ensure they’re making progress in real life. You need to be looking at this holistically, because you don’t want to simply make judgments based solely on number of bugs per line of code, or a number of vulnerabilities introduced in each sprint. You need to apply a human analysis to those statistics and make smart decisions about it if the security training program needs some improvements.
Composition of software engineering teams changes often, new people with no training join, seniors leave organisations, so you can’t really base your opinion on your program based on raw numbers. Of course number of issues is going to go up if you create something innovative using a new programming language or library that no one has ever used before. And that’s totally fine.
Just don’t doubt the whole program or competences of your engineers, instead, create new and relevant content to keep everything up to date. Always have the training program reflect the changes happening is your organisation. If new-hires create many security issues just after joining the organisation, then create a more robust peer review process for them or design a shorter training scenario they must complete before they even sit in front of a computer with access to the Version Control System. You must be proactive in a smart way. You definitely don’t want to be reactive in stress caused by bad numbers.
Last, but not least, you should verify the customer satisfaction, however your customers are end users i.e. engineers using the platforms. You must ensure they don’t hate it. You don’t need to make them love it, but at least check they don’t hate it. And if it happens – and it does happen – then work with users to understand what could be done better, how to improve and what would need to happen for them to use the platform without much resistance.
Part two of the guide will be available soon!