Which topics should an AppSec Training Contemplate?

The development market seems to be becoming more and more aware of the need for Application Security Training (AppSec).

However, the market still looks for generic training, which often meet compliance issues, but do not add real value to development teams. Therefore, this article will present the characteristics and subjects for a good AppSec training.

The Target Audience in AppSec Training

Before presenting the subjects to be covered in an AppSec training, it is necessary to understand who is the main target audience of an application security training. The most complete answer would be: the development teams.

That is, all those involved in the software development process. This includes, but is not limited to, Project Managers, POs, architects, QA and mainly developers (backend and frontend).

Many companies tend to keep at least one person from the Information Security team – besides the instructor – in the training, so that he can take advantage of the opportunity and get closer to the team that is receiving the training, contributing whenever possible with examples of the team’s daily routine.

Note that this target audience may or may not have some prior knowledge of application security. In fact, what often happens is to find mixed classes, in which there are people with previous knowledge in the subject and others who never had contact.

Therefore, some of the following subjects end up being more interesting for some than for others. But it is still highly recommended that all these subjects be considered in the construction of the training, so that the goal of leveling the team members is achieved. Unless, of course, the objective is a training dedicated to a specific profile of employees within the development team, with a certain prior knowledge.

Awareness

Often members of the development team are required to participate in security training. This automatically causes them to lose interest in the subject and perhaps not even pay attention to the content.

Another thing that sometimes happens is that the developer participates in the training, even if by his own will, but does not have the real vision of why this content is relevant to him.

Therefore, it becomes highly interesting that a stage of Awareness is contemplated during the training. On average, something around 6% of the training.

We are talking about presenting here relevant cases of exploration, preferably close to the area of the development team. An excellent approach is to present cases of cyber attacks from the company itself, or at least from competitors (public). Once the team visualizes that the system in which they work may be subject to real attacks from cybercriminals, interest in the training contents begins to be aroused.

Moreover, here it is good to reinforce to the student the advantages of having the knowledge in secure development. After all, we are talking about making them professionals that, today, are still seen as a differential in the market.

Of course, if it is a team that already has a security culture, or that already has the interest in training, this subject does not become more essential to training, but it can still be considered.

Concepts

Conduct a training that contemplates only theory and you will have students who will not know how to apply this knowledge in practice. Conduct a training with only practical activities and you will have students who will only know what to do in scenarios exactly the same or very similar to the practice performed.

A balance must be found between theory and practice when composing a training. And this applies to any type of training.

Therefore, there is no escape – it is necessary, yes, that for a good Security of Applications training the basic theoretical concepts are presented. Definitions and nomenclatures must be clarified so that the class can have a better use of the training.

It is not uncommon for developers not to understand what a vulnerability actually is. It is also not uncommon that they do not know the difference between authentication and authorization, for example. That is: questions that need to be clear to the learner before proceeding to the main part of the training.

Some subjects that can be contemplated include, but are not limited to:

• Definition of “secure state”
• CIA Triad
• Security by default
• Security by design
• Security by obscurity
• Defense in Depth/Layer
• Definition of vulnerability in software
• Privacy definition

If the training is intended for a very mature team already experienced in security, these subjects may not be necessary. Otherwise, they become essential to the training. Separate for this purpose something around 6% of the training.

Secure Development Process

When thinking about security, one should be careful not to think only of the specific part and stop visualizing the whole. This is a vision that should be brought to development teams.

Here the main objective is to show that security is something that should be contemplated throughout the software development cycle and to present to the students what each one can be doing in their daily lives to add to their security.

A team that understands what should be done in each stage of the development process distributes the activities among themselves better and understands their role in software security.

Some subjects that can be contemplated include, but are not limited to:

• Shift-left testing
• Secure development processes (S-SDLC)
• Inserting security activities in the development pipeline
• Knowing the main security checks (SAST, DAST, Threat Modeling, Architecture Reviews…)
• Vulnerability management
• Knowing security maturity models under development (BSIMM, OWASP SAMM)

This subject is essential for AppSec training. Even if the team is more experienced, the debate about possible improvements in the process is always welcome. Consider for this something around 10% of the training.

If you want to better understand about the Secure Development Process, how to manage it, or if you want to better understand maturity models in development like OWASP SAMM, check out some of our other articles about it.

Main security vulnerabilities

The vast majority of Application Security training contemplates this content, and for a good reason. Some implementations and certifications, such as PCI-DSS for example, require the development team to be trained in the main market vulnerabilities at least once a year.

“Developers are trained at least annually in up-to-date secure encryption techniques, including how to avoid common encryption vulnerabilities”. – PCI-DSS Requirement 6.5

And in fact, large entities in the software security world generate lists of the main vulnerabilities in the market, based on statistical data, such as the OWASP Top 10. Or they also list the main errors in software development, such as the CWE/SANS Top 25 list. These lists are generated with the main purpose of educating developers around the world about these scenarios.

In training where there is a specific language to be addressed, it is highly recommended to bring examples of vulnerable code from this specific language. Another option that enhances this type of content is to present examples of vulnerabilities of the company itself. After all, easier than understanding a generic vulnerable scenario is a developer understanding the vulnerability in a code or infrastructure that he knows.

In the case of Conviso’s training courses, for example, when we perform code tests or revisions for a company and then carry out training to train development teams, if the company authorizes it, we bring examples of vulnerabilities found in the company’s own systems for training. This adds a lot to the learning, besides making the teams leave the training with that feeling of “now I know what to do”.

Some subjects that can be contemplated include, but are not limited to:

• OWASP Top 10
• CWE/SANS Top 25
• Company’s main vulnerability

Consider for this something around 14% to 20% of the training. But be careful not to focus too much on this subject, since the next subject is even more important for this type of training.

Main best practices in secure development

This topic can’t be missed in an Application Security training. If the goal is to teach development teams how to build more secure software, this is a subject that cannot be missing.

If it is a training without focus on some programming language, this part can be focused on the concepts so that, regardless of the language used, the student knows what should be done. However, when there is a focus on some specific language, it is important that in the presentation of these good practices are presented examples of code, documentation of frameworks and things like that, to show in the language of the developer how these concepts can be applied. This makes the training something much closer to the reality of the developer.

But beware! Many companies seek security training focused on a set of languages. However, it is worth remembering that if many languages are contemplated in a single training, it may be that not one of them is deepened and becomes a shallow training. Therefore, when there are several languages, it often becomes more interesting to focus on the concepts or divide them into several trainings.

There are several subjects that can be contemplated here, such as:

• Authentication;
• Session Management;
• Access Control;
• Security in Architecture;
• Cryptography;
• Security Best Practices in APIs;
• Security Settings;
• Security in Cloud environments;
• Security in web services;
• Input Validation;
• Coding and Data Escape;
• Secure Database Queries
• Security and monitoring logs; among several others.

Try to understand your team’s needs and select themes accordingly. Some excellent references that can be used to select these themes include, but are not limited to:

• NIST SP 800-XXX
• OWASP ASVS
• OWASP Proactive Controls
• OWASP Cheat Sheet Series 

Separate something around 14% to 28% of the training. 

An excellent approach is to present the good practices in development together with the main vulnerabilities, because the two subjects are quite complementary.

Learn by doing

If possible, seek training that also includes practical activities. After all, as already demonstrated by William Glasser, the human being learns much better by doing (80%) than just watching (50%).

But beware! It is important to keep in mind the target audience of this type of training. Members of the development team are not security specialists nor are they responsible, in most cases, for performing combs. Therefore, a good Application Security training cannot become a pentest training.

Ideally, practical activities should be carried out both in exploiting vulnerabilities and in remediation. After all, developers like to “see code” and in everyday life what they will have to do is just write secure code.

In Conviso, for example, companies that acquire the education module of Conviso Platform, will be able to perform practical exercises of exploration and correction of vulnerabilities that are reported in their systems, with exercises in the most diverse languages.

Of course, practical code correction activities can only be performed if there is a language focused on the training. If there isn’t, some simpler codes can still be reviewed, easy to be understood even by a developer who doesn’t know that language very well, but nothing very specific.

Consider something around 40% to 50% of the training for practical activities.

Just don’t stop there!

Conducting an Application Security training like the one proposed in this article should only be the beginning of a learning journey for the development teams.

As far as possible, education programs should be structured in the company, so that the employees can always be evolving in matters related to security and keeping themselves updated.

Specific training focused on specific profiles within the development teams should also be considered, such as training specifically for API or Mobile application development teams. Or perhaps training focused on architectural security and threat modeling for a team of software architects, for example.

The development team’s deficiencies with regard to secure development should be understood and training selected accordingly.

If you want to know more about AppSec training, you can also check more articles on this theme.

Article by: Nicolas Schmaltz