Continuous Reminder

Incentivising developers to know the importance of security is all very well, but faced with normal life people forget quite quickly. So make sure you have a trickle of regular events and nudges to remind the team.

While your initial Incentivisation Session may be effective, its impact is relatively short-term. After a few weeks or months we usually find that the drive of the development team to do security tends to be lost. 

To counter this, it’s important to keep reminding the team of the need for security. Typically this needs to be at least every month. You can think of the technique as kinds of ‘nudge’: small reminders of the importance of security issues. 

The Developer Essentials package approaches Continuous Reminder as a monthly follow up session devoted to security. Typically, the session will look back on what has been achieved over the previous month, what problems there have been and how to address them, and what security improvement opportunities there are for the team in the next session.

During these sessions  is the right time to consider some of the other possible steps discussed in this book, specifically:

• Security Negotiation – How effective is this being, and how to improve it.
• Security Champion – could someone take on this role, and how to support them?
• Code Review – is this workable?
• Penetration Testing – Is it a financial and practical possibility?

The delightful thing about Continuous Reminders is that there are many ways of doing them, limited only by the team’s ingenuity. The following are some example of ‘nudges’ we’ve encountered. 

An excellent approach is positive feedback built into the development process. It’s very effective to give developers small encouragements for their successes related to security, even quite small ones.

The other thing I have to mention is the feedback loop. A pen test report or even just a static code analysis coming back and saying you are doing well – having a desk report or the executive summary that says “wow that is a really secure application, well done!” (Security trainer & consultant)

Some companies organise a monthly security competition, defining teams and awarding points based on the security success of each.

We tally the results, and there is a league table, and the team at the top get a prize and a little trophy, and we have these 'town halls' and all that.  (Security expert, Internet infrastructure provider)

Others work through security checklists, such as the OWASP Top Ten, concentrating on a new item each month.

This kind of positive feedback may even be built into automated tools. For example Detectify, an online web security review tool, produces encouraging feedback to its users in the manner of fitness apps, before making suggestions for improvement. 

Now you have 8 out of 10. Nice work! (Detectify)

We strongly recommend using a similar ‘nudge’ approach with other stakeholders. Use incidents in the news to remind product management and senior management of the importance of security.

Never waste a public disaster. If it is in the news, everyone here has read about it. Like Sony: we went straight to our VPs and said “right, what if that was [us]? What would you do, how would we cope, how would we react, what would it do to our share price?” (Security team lead, Operating system supplier)

Somewhat more heavyweight, but often very effective, are training sessions. A commercial training course might be useful. But even more helpful are regular events of different kinds. They too act as regular ‘nudges’, reminding the team of the importance of software security.

Some teams have found ‘Brown Bag’ Sessions very helpful. These are lunchtime sessions, where food is provided or people bring their sandwiches to eat. For security, these sessions generally use informal presentations and discussions involving the whole team. Because they are valuable as nudges, it is more important that they happen than that any given talk is particularly good!

A presentation that leads to an animated discussion between team members is excellent. The people to lead them might be a security champion, or an external security expert. Typical topics might be sharing recent security experience from one’s own and related projects; or working through and discussing different kinds of security issues, such as the OWASP Top Ten.

[Our security specialist] will take the most interesting or most relevant findings for the team out, and those go into a slide deck that we keep, and that deck is used as part of a show and tell. That happens… a few times a year. (CEO, outsourced secure web developer)

Another possibility is for developers to work together through some of the ‘ethical hacking’ training materials to learn how an attacker might work. There is a variety of courses available; however almost all concentrate on purely technical attacks, so we recommend having other forms of training as well. A discussion on Quora here gives some idea of the range of hacking training available. 

I think training is obviously very effective, and we sometimes do specialized training. ... So we had pen testers coming in, and I have got it so that we can now do it ourselves, where we have got a VMWare image with all the hacking tools on it, and vulnerable webpages, so they can play and see how easy it is – and what issues they need to look for. (Security expert, Web infrastructure provider)