How to stay secure for longer? Software development case.
Do you want your software to be secure in its DNA? This post is our overview of two possible ways to improve security awareness in your organization.
How to stay secure for longer? Software development case.
I address this post in particular to senior developers, team leaders, project managers, scrum masters, or architects – or anyone who cares about quality and appropriate level of security.
During the security awareness seminars I organized, I had hundreds of coffee talks with developers, and they provided me with important insights into application security from their perspective – both the issues they encounter and the solutions they are contemplating or have implemented. Some themes were coming up again and again, so I decided to gather them all and share them with a broader audience in the hopes that they might help others.
I’d like to highlight some of the ideas I’ve presented over the last several years for sparking interest in appsec subjects among developers, devops, testers, and other individuals involved in application development. If you wish to create or enhance an application security program in the software industry, this article is for you.
I found six unique methods to putting security in place in your organization:
- Hackathon
- IT Sec on the run
- Threat modelling
- Security Champions
- Trainings
- Internal Bug bounty
We’ll focus on the third pair of options in this post, but if you want to see all six suggestions right away, go to our playbook.
Security training for your project team
A good security training can be an eye-opener for developers, testers and devops, literally anyone involved in software development. Important thing, when searching for such training is to find a good balance between offence and defence – show the root cause of security problems for developers and not to dive too deep into finding and exploiting vulnerabilities but go into fixing.
Developers should understand the problem and not necessarily know how to find and exploit it (except from the source code perspective of course). One more thing – from my experience it is best when the whole team takes training or workshop together and discusses the security of their project, the good training should allow such discussions of issues from trainees day to day tasks.
Pros
- raises the security awareness
- teaches different vulnerability classes and shows root causes
- allows to exchange knowledge and experience between trainer and the group, or inside the group
Cons
- if one time activity if fades away in time
- too focused on the offensive side will not help developers work with the source code
- take out whole team for 1-2 days
Now to tackle the problem of taking the whole team out we made an online training, to allow flexibility in taking lessons. You can get our Hackflix here, trailer of the first season is available here. If you prefer to meet for the whole day and select modules you’re most interested in, we have the Security Aware Developer course, check it out here.
Internal Bug bounty – a fun hacking for your own good
When you wish to increase the security impact of the source code review (when code review is a standardized practice in your organization after a developer makes a pull request), and also dedicate more time to security tests done by testers alongside the usual testing – there is one way to go.
You can establish an internal bug bounty programme, where reporters will receive some kind of gratification when they report a valid security issue. The most tricky part is figuring out the proper rewards.
If rewards will be too valuable, you can see some abuses of the program rules done by let’s say “creative” people. On the contrary, if you propose something without real value the bug bounty programme may get much less attention than intended. To give you some ideas for rewards that can actually work:
- bug hunter’s t-shirt (if your developers like and wear company branded clothing) or some other swag given exclusively for bug bounty activity (stickers, posters etc.)
- points to the cafeteria system that you use (if you use any), the exact value given as a reward may require some trials and errors
- a trophy (for the best bug, or for the best findings – rules of selecting the winner should be crystal clear), where the winner should be selected monthly (quarterly etc.) and the trophy is passed to her or him from the previous winner
Always include the public shoutout for all reporters which found the valid issues.
When dealing with handling reports, a word of caution – there may be poor reports coming – bugs with no risk impact or missing best practice.
The people responsible for report review (deciding if this is a valid vulnerability and determining the severity of it) should not discourage reporters, instead it is an opportunity to teach them and explain things. Patience and very good communication skills are required!
Good bug bounty programme scope (especially a list finding that are not eligible) will help.
Pros
- increased interest in security topics
- discovered vulnerabilities which sometimes are much harder to find by the penetration test (due to vast knowledge of internals of the app by the reporter)
Cons
- sometimes difficult to set proper rewards
- poor report quality
Which method should you take?
Training and Internal Bug Bounty aren’t the only possibilities. There are also IT Security on the Run, Hackathons, Threat modeling, and Security Champions, as I mentioned at the beginning of this series. However, it doesn’t stop there eithers, and there is always something in between. You can combine them or select one depending on the resources you can allocate. Pulling off any of it requires soft skills to persuade the management to it, some office politics may be involved. Moreover you have to provide appropriate security skills, depending on the selected activity.
The list is not complete, so stay tuned for a more complete catalog! Also feel free to connect with me in case you have questions.
To help you navigate through the ideas we’ve put together a fun playbook with the correct questions to ask yourself. Each of the six approaches outlined above is only a single click away.
But, remember that…
Improving application security in my opinion requires a different set of activities and, moreover, that those activities are repeated and improved over time. One small spark will not have a long-lasting impact. Therefore, to build and maintain an application security program in a company, the leadership support is essential. Developers should know that application security is one of the company’s priorities. If there are only expectations that the applications will be secure, but there are no means to actually focus on security (money or time), nothing will change, so either you fight for those means or you leave ;).
If you have any questions or would want to discuss the potential of incorporating protection into your company, please use our contact form.
Head of Web Security
