Incentivising Developers

Carry out a course, workshop or discussion to persuade your developers to take security seriously.

"Why should I care?" It’s there in your colleagues’ eyes, in their attitude. Software security is not a part of most software development. They don’t even teach it much in university, yet. Many developers and testers won’t have encountered it at all, or will consider it something for other groups to handle.

Or maybe they have encountered it, and consider it too expensive, or too painful, to confront. 

If we want our team committed to improving software security, we need to change that way of thinking. In particular, we need to address the problems in ways that are meaningful for this team, in the context of the work they’re doing. But how do we convince them that security isn’t ‘somebody else’s problem’? How do we motivate them to start taking it seriously?

We need some kind of Incentivisation Session...

For the Developer Essentials package, the Incentivisation Session takes the format of the Agile App Security Game. It doesn’t need security expertise to run, making it suitable for teams who don’t have security experts available.

The Agile App Security Game involves groups of up to eight people all taking the role of Product Manager for a mobile application development. The facilitator has the role of ‘games master’, following instructions provided in the game. The players chose ‘security story’ cards for each development cycle, and then discover, based on the outcomes described by the facilitator, how successful they have been in deterring security threats.

It’s good fun, and participants generally enjoy playing. It introduces very effectively the principle that the Product Manager is the one to make decisions about security cost/benefit trade-offs. Its limitations are that it doesn’t consider privacy aspects, and concentrates on relatively anonymous threats, ignoring others (such as insider fraud and customer repudiation of transactions) that might be equally valid. It’s worth the facilitator saying as much at the end of the game.

You can download full instructions for the Agile App Security Game here:

There are several other ways to use the power of group discussion and learning, using a variety of team activities or even one-to-one discussion. All three of the following are widely used by more security-expert teams:

• Pen test workshop,
• A security lecture, or
• The Talk

Considering each of these in turn:

Penetration testers are software security specialists; they ‘wear the hat’ of a possible attacker and try to break into the software you have produced. A good ‘pen tester’ may be able to work with the developers and show them the kinds of things an attacker can do. By doing so, they can convince the developers and testers that their software already has a problem. 

With these companies, we would do an initial project where, for example, we pen test one of their existing products, and show them “this is how you designed this product, and this is how you went through this process, and this is what we found (Professor, German research organisation) 

This is very much the ‘traditional’ incentivisation workshop, since many security specialists are expert pen testers. It’s excellent in one way – it is very immediate and links in immediately to the context of the development team. It does have disadvantages as an approach, though. First, it sets the specialist up as an ‘adversary’ to the development team, which makes it more difficult for that specialist to be seen as a helper later on. Second, it tends to give the impression that software security is about low-level fixes to existing code, whereas often the biggest security issues are related to design and usability. Third, it’s no use at the start of a project when there’s no code to test.

Some bigger companies, with thousands of developers to bring up to speed with security, use the traditional teaching approach of couple of days of lectures. As an approach it works only when the teachers are really expert and know a great deal that is relevant to the company.

So we run a very large scale education programme …  where we …  tell developers exactly what happens in the real world, how TalkTalk was hacked, how Sony was hacked. And then we go in detail how we have been attacked, and whether they were successful and how they were detected. Then we also show them all the stuff that our red teams do – our internal hackers – which really scares them!  (Security team lead, Operating system supplier)

When there’s only one developer involved – for example a new joiner to the team – the approaches above don’t really work. Many companies, instead, have a discussion between someone who knows the issues and the new joiners.

The conversation can take anywhere between 40 mins to several hours depending on who the person is, and you won’t know until you’ve had the conversation. And the conversation is, you explain how to break into, how an attacker would attack the systems, and what the various things you need to be aware of, are. (Security consultant and pen tester)

This is not easy; the trick is to link the issues to something that has meaning for the developer in question. One expert aims to find out situations with the developer’s own family and friends where software security is an issue, and then uses that as a hook to relate that to the software they themselves will be developing. 

Don’t leave the developers scared! Conventional software security wisdom used to be to ‘scare developers and leave them scared’. Our experts don’t agree – instead they stress that the event should leave developers aware of security issues, but confident in their ability to address them.

It needs to be positive. That is why the day is balanced. For every one of these problems we show you in the commercial world and internally, we absolutely have a way of mitigating it. And even if we know we can’t stop it, we can certainly detect it, contain it and then exfiltrate those people. (Security team lead, Operating system supplier)