Deciding on Investing in Application Security Training for Your Developers?

People are the backbone of any business. Yet, lots of data points suggest that the human is the weakest link in the security chain. In a 2020 survey, it was revealed that 65% of cybersecurity professionals have accessed documents not related to their job profiles. The same survey also noted that nearly 40% of respondents admitted to abusing their access after receiving bad performance reviews, and 86% of security professionals they’ve clicked on links from unknown sources. Application security training for developers is crucial now more than ever.

For most CTOs, their teams consist mainly of technical employees including developers, architects, development managers, quality assurance, UX, project managers, etc. Technical staff in any technical organization usually hold privileged access to source code, backend systems, databases with client data, cloud frameworks, etc. 

Most CTOs that we talk to focus on one type of training versus the other. For example, in early stages, with most of the staff being technical, CTOs might focus on technical secure code training. However, to build a wholesome security culture you have to consider the different aspects of security that your developers need access to. 

Types of Developer Application Security Training:

1 General Security Awareness

This is a high level security training for employees. Usually, security awareness training focuses on general security hygiene such as understanding the basic concepts of social engineering and other phishing attacks. Many CTOs make the assumption that technical staff are better equipped to deal with phishing and social engineering than other non-technical staff. While there is some truth to that, the attack scene is changing so fast. Software developers are becoming the prime target for social engineering as they have a higher level of admin access to multiple systems.

2 Secure Coding Best Practices

“Good” code does not always mean secure code. 

While most developers are easily able to identify what good code looks like, they don’t know how to identify secure code. Knowing the most prevalent bugs in application security programs should be a top priority for any development team. If your team doesn’t already have this foundation, we recommend at least a well-rounded, base-level application security training for your developers in order to understand the top bugs and how to find them. A good place to start is through an OWASP Top 10 training, which teaches developers the most important techniques to write secure code in any language.

3 Security Operations Best Practices

Not all security breaches happen through a phishing email or a SQL Injection in the application. There are other scenarios that can lead to a security breach. For example, the lack of security operations best practices including password storage, internal system onboarding, off boarding, setting up cloud infrastructure in an insecure manner, building secure images, etc.

Taking a training course does not mean that employee behavior regarding security will change completely. Different people will react differently to the information they intake during the training. After providing employees with the necessary information via training, you need to start thinking about how to encourage behavior change following the course. 

Encourage Your Employees to Adopt Secure Best Practices

Your goal after the training is to enable behaviour change. Taking the training gives your team the information necessary to understand best security practices, secure coding looks like and what a secure software development lifecycle looks like. However, this is just the beginning of the work. This is not nearly enough to  There are several techniques you can choose from to allow for behaviour change.

1 Strong Management Support

Without putting enough management power behind the initiative, the training won’t go that far. Your team has to understand that the training is just the first step in the journey and you don’t intend to stop there. Your actions from that point needs to send strong signals that security is here to stay. Extra points if you can tie it to job performance.

2 Empowering Security Champion(s)

One of the best ways you can empower behaviour change is through security champions. In today’s software development culture, there is an ever-increasing need for management to drive empowerment within their teams. You need to seek out, identify, and empower someone who can act as your team’s security champion. Find at least one champion to start, and add more if they are available. As you grow, you may even consider assembling a Security Champions team.  

Security champions are not necessarily security experts but they must have passion for security and they are able to get people around them passionate as well.  Your champion can be a current team member or a qualified contractor/consultant. A thorough knowledge of the team’s goals is necessary. A security champion needs to be a positive person that can offer diligent observations and constructive suggestions to the team.

Your security champion will promote the best practices in application security. They will work with your systems architecture and engineering teams, and with DevOps and DevSecOps project leaders. You may choose someone who has excelled in their Application Security Training courses, as an example.

With their knowledge of security threats and remediation methods, champions are qualified to consult with developers and contribute meaningful recommendations for practices and tools. They also provide support in preventing and eliminating security problems earlier in the software development lifecycle. 

Your security champion(s) will act as the reminder to be conscious about security in team meetings and design sessions.

3 Establish Basic Metrics

You can’t improve what you can’t measure. Especially if you are a small team, it could be a daunting task to measure security efforts. However, it is very important. 

Here are a few KPIs you can use to understand if you are moving in the right direction:

1. The number of vulnerabilities discovered: there should be less and less bugs discovered as your security team matures.
2. Average time to remediate security vulnerabilities: this measures your team's understanding of the bugs and the mitigations
3. The number of requirements tagged “Security”: one sign of security maturity is thinking about security requirements early on in the process. Tagging requirements with “security” helps to measure this KPI
4. Compliance metrics: if you are under SOCII, HIPAA, PIPEDA, or similar, they can help you understand your security maturity.
5. Amount of time spent on security questionnaire: having documented security processes help you answer security questionnaires faster. 
6. Code coverage: how much code has been covered by your existing security testing efforts.

Number of tests: this measures how many security tests are you running against your systems both manually and automatically.