Lastly, we turn to the two further techniques used by the experts interviewed in their intervention work. First, an Incentivisation Session, which is a presentation, discussion or workshop to help motivate those involved for the need for security.
4.11.1 Context
Given that a large number of developers have no current interest in security [200], it is vital that at least one intervention generates such interest. The Active Developer Model makes it clear that without such interest, developers will avoid security-improving activities.
4.11.2 Solution
Thus, most of the interviewees discussed a form of presentation or workshop to help motivate those involved for the need for security:
Everyone who joins [this company] gets a security talk, when they are a developer that security talk is longer. And it includes examples of things that have gone wrong and why, and how badly these things can go wrong, and how easy it is to screw it up, and some pointers on things to read about, to learn about. (P1)
Some provide it as a scheduled training course for new employees:
I get an email every week, and it tells me how many new starters there are, so I know, okay, yeah, there is about 4 or 5, I’ll do an induction. (P12) Others make it a one-to-one between the intervener and each developer:
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. (P9)
Bigger companies may offer a security sensitisation course over several days for every programmer:
So we run a very large scale education program … 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! (P5)
Sometime the Incentivisation Session is based on a penetration test of the live systems; the intervener carries out the penetration test, identifies a list of vulnerabilities in the
software, and uses those to convince the developers of the importance of improving their security. From the point of view of an external security specialist this may also be an opportunity to establish their credibility:
What is often a door-opener for us is, 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”. And ideally, we try to then point out to them “this is where you might have detected it earlier, but this is why it failed, why you failed to detect it”. And this is often an eye opener for them, because then they see that a better process might be more worthwhile. (P13)
4.11.3 Execution
However it may be carried out, the aim of the Incentivisation session is to motivate the developers themselves to understand and prevent security problems. So many such sessions include stories and warnings about the consequences of security failures:
I talk to my engineers about this, about look at what is happening in the courts – look at the class actions, look at these things. It is a hard thing to say, but you guys do not get away with saying “it’s nothing to do with me” (P6)
Many covered a variety of different kinds of security problem, not limited to purely technical ones. So, for example, some include discussions about how aspects of team working may cause security problems:
So we give them that kind of perspective, it really brings it home: if you do X, this is the result. If don’t work together as a team – if you don’t work with your dependencies, this is what happens to you. (P5)
Conventional software security wisdom used to be to ‘scare developers into security’. We wondered if this was actually the best approach, and asked our interviewees directly if they did this. The consensus from our interviews was definitely not to leave them scared:
I must admit, we had [high-profile expert] to visit and he goes off on one of his rants and scares the shit out of people, and they think “oh there is no point then!” (P5)
Instead it is essential to leave developers knowing that the problem is solvable, and so each session needs to show that solutions do exist for the problems they are introducing. The Incentivisation Session works by highlighting problems and leaving possible actionable solutions:
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. (P5)
Overall, the interviewees designed their sessions to convey a positive aspect to software security: that it is an interesting and exciting topic, a valuable skill to learn, and that secure implementations give value to their organisation and end users:
I try to emphasise the positive aspects: “This is exciting, this is interesting.” Fear is probably the wrong word, but awareness is the right word. … The
Chapter 4: Expert Survey
awareness that someone can attack your application is definitely scary – especially from the perspective of someone who owns the business – there is nothing wrong with that, you shouldn’t try to scare them; you try to share solutions to empower them. (P11)
All of the experts who discussed an Incentivisation Session emphasised this in one way or another.