Today we would like to cover the topic of security training in companies that develop applications – and not just mobile applications. In this article, we will share ideas for building a Center of Competence in a company. We will also talk about how to engage developers and how to help them get involved in the topic of security of applications being developed.
Unfortunately, in some companies, security and development teams are still on opposite sides of barricades and do not want to listen to each other. On the one side there are nasty security specialists who put sticks in the wheels and block product releases, and on the other side there are careless developers who do not want to fulfill the requirements of information security. All parties involved suffer from this approach, and most importantly, so does the product itself.
There are often a lot of vulnerabilities in applications. In this case, it is said that developers have written code that is really bad from a security point of view. But where do vulnerabilities come from and how do they get into the code? They don’t leave them there on purpose, do they?
Vulnerabilities do not get into the code because someone does not write programs well or fails to comply with IS requirements. The reason is that a security analyst or an attacker has a very different view of an application than the application developer. For developers, the most important thing is proper and high-quality functionality and product usability. For attackers, each newly added functionality is a new entry point into the application that needs to be evaluated for penetration.
As a quick example, let’s look at a simple file download from client to server. What could be easier? Write a convenient API, connect subsystems, write several checks for file type by extension. What does a security analyst see here? Well, a huge field for experiments: directory traversal, XSS, XXE, internal file overwriting, and much, much more.
How can developers know about all the nuances and ways to exploit vulnerabilities if their daily work is to create functionality for end users? The obvious conclusion is that developers need to be trained on which points to pay closer attention to. You need to tell them about different types of security flaws, show them live examples of how such vulnerabilities were exploited, and of course, let them try to find and exploit them themselves! There is no doubt that many programmers are quite skilled in security, but still most have heard something about it, but have not delved into it deeply. This is especially evident in mobile applications, where we constantly encounter “childhood diseases” of security during their analysis.
Principle of building training
Typical problems are most common in mobile applications. Their remediation and prevention in the future depends directly on the developers’ understanding of the reasons for their occurrence and the ways of their further exploitation. Understanding of this should be conveyed to all developers in the company. Moreover, testers will also benefit from understanding how to test applications not only functionally, but also for security, and what should be added to test scenarios to analyze IS issues in applications.
Internal Application Security Portal
The first thing to start with is creating an internal application security portal. Here you should collect all available materials on this topic. It should be a single point of entry for all aspects of the secure development process, and maybe for all security related topics in general.
Anything that is already in use in the company can be suitable as a site. The main requirements for selection are quick launch of the portal and ability to collect in one place everything that is already there. Why do you need it? First of all, it’s just convenient. Often in companies, we encountered a situation where each document was searched for unbearably long (in emails, in corporate messengers, in files on different servers, etc.). And how much easier and more convenient it is to have a link to a desired document on the portal. We recommend that you add all of the activities described below to the portal so that they are easy to find and use in your work.
It is important to highlight – you do not need to hire a designer and programmer to develop the portal! All you have to do is create an appropriate section, for example, in Confluence, think of its structure, and upload existing materials there.
When hiring, especially in large companies, employees take various internal process trainings and induction courses. They are often long and boring presentations. But surprisingly enough, the modern platforms on which these courses and presentations are implemented allow you to do amazingly interesting and useful, truly live courses, with questions and interactive elements.
Over the past few years, we have often conducted trainings on mobile application security. During this time, their format and content have undergone significant changes. Now there is much more practice and examples from real life. Over time, there was a desire to turn this into something more autonomous and interesting. We’ve taken all the key types of vulnerabilities from the OWASP Top 10, enriched them with real-life examples, added a bit of theory and introduced a lot of interactive examples into the trainings. What are interactive examples? They require the audience to do certain things, such as “launch an application”, write a command in console, and so on. All of this is done in a game format. Attendees are gradually introduced to the world of vulnerabilities in mobile apps, keeping their attention with a variety of interesting challenges. At the very end of the training, there are always a few slides with information about internal information security department, events held or planned in the company, as well as contacts and links to these materials.
All participants in the mobile app development process – developers, testers, analysts, and security specialists – should receive such trainings.
Each participant should receive an email congratulating them on their successful completion of a training course. This letter should necessarily include all the links and useful materials on training, as well as links to the internal portal and, of course, contacts and a list of upcoming events. This approach can be developed in a company. Employees can be assigned a certain security rating for their achievements, starting, for example, with a “white belt”, that is, introduce elements of competition and gamification.
The trainings prepared in this way are designed to accomplish several important tasks:
- Let everyone involved in the development process know that company pays attention to security.
- Give an overview of vulnerabilities in mobile applications and how to exploit them.
- Give the first link to internal activities and materials that can and should be applied in your work.
- Show who you can turn to in case of questions related to IS.
- Involve employees in awareness programs.
In practice, this simple approach solves a number of problems. With its help we start to promote security among developers, and we do it not with boring lectures and presentations, but with interactive high-quality material with live examples and direct benefit for participants. This is always appreciated and attracts audience attention. Besides, we create a platform for promotion and development of this topic. In addition, we get contacts of all participants in order to continue working with these people in the future.
Secure Development Guidelines
Among the materials stored in the internal knowledge base may be secure development guidelines for programming languages used in the company. They do not have to contain a lot of text and cover all possible issues and frameworks. Rather, they are detailed manuals that are gradually filled in and updated. As a time-saving option, a basic description can be considered as a start, with its subsequent development based on the vulnerabilities found during analysis of applications. Thus, this internal knowledge base will gradually evolve and be enriched with real-life examples of vulnerabilities and recommendations for fixing and preventing them. You can also view various articles and news on new types of attacks and vulnerabilities and make recommendations about them in your internal portal. After a while, this internal base will become a very valuable and useful source of knowledge for development. To promote this approach, it is very good, when you enter information about a security flaw into development bug tracking system, to immediately refer to a relevant article or section in these secure development guidelines.
In our experience we can say that after a while, developers themselves begin to give references to these guidelines. It is much more convenient to read about how to fix a problem and prevent it in the future, when everything has already been found and structured for you than search for advice on the Internet. Moreover, reading these guidelines becomes almost obligatory for newly joined colleagues. The most important and most difficult thing is to keep these guidelines up to date and understandable. In our case, every month we update our recommendations to remediate the identified vulnerabilities, even if it’s just one or two lines of code or adding a few links to related articles. The main principle here is to update the information regularly so that it can actually be used.
Various online trainings in the format of video lectures with periodic assignments in between have also proven effective. It’s more in-depth than interactive courses. It provides much more detail about what and how things happen in mobile applications in terms of security, what protection mechanisms the operating system itself provides, how they work, and how to use them. This material should be illustrated with real examples of exploitation of vulnerabilities and how to analyze applications and identify such problems and what to look for. Since much more time is available for mastering the material, training can be broken down into separate sections or chapters. You can view them in parts and at your convenience.
But there is a nuance in this type of training – they work well only when several conditions are met simultaneously:
- Training must be well prepared. It should not contain lengthy arguments and outdated materials. Only on the case and only from recognized experts. The material should contain the necessary set of themes that will be applicable to your applications and possibly take into account your specifics.
- This training should be taken by those who find it really useful and interesting. You should not force everyone who has taken an introductory interactive course to take it. There must be a desire of developers/testers/analysts to take this course.
Organizing an online training session is not time-consuming. It is enough to choose a course, agree with the provider about its possible modification for your specifics, upload this course to the internal system and announce free registration. Thus, having prepared this material, you can periodically update it with fresh and relevant data. It is also important to collect feedback from those who have taken the course, so that in the future it can be improved and missing points can be added. In our case, the number of such iterations exceeded about two dozen courses, conducted with their adaptation into a video format with assignments based on the results of the courses by a variety of specialists.
Such courses bring very good results with the right choice of material. If you really interest trainees and show them how to use certain vulnerabilities in practice, in the vast majority of cases, after the training, trainees will want to try the acquired knowledge on their own experience in their applications. And who knows these applications better than the people who have developed them themselves and tested them hundreds of times! We’ve had cases where, after the training, trainees have found some vulnerabilities in their applications and fixed them on their own!
Another important aspect can be noted. People who self-selected and completed such trainings are potentially a key audience for the further development of their security competencies.
The next item of our conversation is open meetups on security topics. Anyone can participate. Here it is possible and necessary to combine several approaches – to make meetups by your own efforts and speak by yourself, to invite various industry experts and to provide the right to speak to everyone who wants to say something interesting about security.
We have conducted such meetups on several subjects with our own resources:
- We launched a survey within the company – what topic you would like to hear a report on: Android KeyStore operation, working with Security Enclave, proper use of biometrics, etc. We collected votes, chose a topic that interested the most people, conducted research on it, and presented it to everyone who wanted to hear it. It does not take a lot of time to prepare – choose a topic, prepare a report only on it and talk about how it works and how to apply it (or exploit it if it is a vulnerability). Based on the presentation results, the content was added to appropriate section of Secure Development Guidelines.
- From vulnerabilities we regularly found in applications, we identified the three most common ones, got everyone together for a meeting, and discussed ways to solve these problems. It wasn’t very time-consuming either, since we were still writing materials into our Secure Development Guidelines. In fact, we just did an extended report on the same topic.
Invited experts can range from those who know how to find amazing vulnerabilities and can talk about them, to those who are good at closing or preventing those vulnerabilities. Various security teams or developers from other companies can tell you how their process is set up, what they pay attention to, how they perform testing, etc. Sharing experiences is always a very useful and good practice.
But you shouldn’t forget about your colleagues. It’s likely that some of them will be happy to talk about their security experience, challenges they have faced in remediating vulnerabilities, and the solutions they have developed.
The format of such events can be very different – from a meeting in a cafe to a formal appointment. But as practice shows, the most appropriate format is a meeting in the office in an informal atmosphere, with beer and pizza. In this case, some people will come, if not to presentations, then at least for free food. In this case, a meetup can take place at the end of a workday, so as not to force participants to stay up late after work. In this case, there is another additional advantage of building relationship between the development and security teams, communicating in an informal setting. This increases developer loyalty. If material presented at the meetup is of high quality, developers understand that security people know what they’re doing, which means that defects created by them still need to be fixed.
If you also record speeches at the meetup and publish them on an internal portal, you can get another great benefit from the event.
This item requires much more time, but it can bring unexpected and very interesting results. CTF stands for Capture the Flag. It is a game format. The goal of the game is to earn flags. In our case we are talking about a specially prepared application containing vulnerabilities. It is necessary to find these vulnerabilities and exploit them. For each finding player receives a flag, which brings a certain number of points depending on the vulnerability complexity. The winner is a participant with the highest number of points.
For a CTF pilot game, you can take one of the publicly available versions of the game from the existing ones and arrange a competition within the company. It would be great if we could get at least a small budget and give souvenirs to the winners. This can be not only material values, but also, for example, a printed certificate with a funny and pleasant text, signed by CEO, etc.
Competitions in this format can be organized relatively easily. You will see how exciting they are for the participants. It makes sense to invite absolutely everyone and keep things interesting by sending clues or summarizing intermediate results with a leaderboard.
In our experience, not many people took part in the first game, but we continued to perform all of the activities described above. At the time of the second CTF, it was already a tremendous success. At the end of such events, be sure to hold an awards ceremony, review all the tasks and their solutions, and announce that this is not the last such event. This gives a good topic for the next newsletter and a reason to visit the internal portal.
Developers who perform best in CTFs are also potentially a key audience for developing their security competencies in the future.
Another good way to make yourself known and maintain interest in security is through regular email newsletters. If you have a group of people who participated in training, you can send them a newsletter about once a week so they don’t get bored and you don’t spend a lot of time on it. Newsletter topics can be very different, such as a compilation of interesting articles for the week (news, tool reviews or just small interesting notes), descriptions of new vulnerabilities, CTF results, and anything else you think is relevant and interesting. The key is to keep it regular and don’t skip sending emails. Make it a rule to spend 10-15 minutes every morning looking for interesting things, and you won’t notice how by the end of the week you’ll have enough material to post.
When we got to the regularity of sending and everyone got used to getting a security letter once a week, a couple of times we forgot to send it on time. They began to ask us if there was going to be another newsletter. Many people liked it and were already waiting for security team to send more interesting material.
And, of course, all links and news from newsletters should be placed on the internal portal. It will only benefit from this.
As a rule, there is one security specialist for every hundred developers in companies, and this is still an optimistic estimate. Tracking all the results of security tools alone, even with a well-established automatic integration process, is a very difficult task. So the only way to make a truly secure product is to get developers interested in security, train them using the methods described in this article, and thus spread security expertise into every project and every product released. In this article, we have given only basic examples and methods that we use that give very good results. Take them on board, expand, improve, and adapt to your own processes!