A year ago I started researching software security. I started by interviewing a dozen very experienced experts, and analysing what they said.
In their answers I found something very different from what I’d seen in the literature.
Much of the writing about software security tells programmers to use checklists of possible errors; the implication is that if the checklist is satisfied, the software is secure. Alas, this isn’t true.
Checklists help, but many of the things that cause bad security are nothing to do with low-level errors. They are the results of interactions between different parts of a system, faults in components used, or simply unrealistic demands on the users.
As a result, our experts were saying, we have a much bigger problem than just inappropriate software constructs. It’s the kind of problem it needs more than one person to tackle. In fact, to solve it for any particular application it needs lots of communication, discussion, challenges, and reflection. Of these, I found, what is particularly important is challenges. The reason is that what causes security problems is things programmers don’t expect; to help programmers we need to ‘jog’ their thinking by challenging them. In writing up the findings I call that kind of interaction ‘dialectic’: asking questions.
Fortunately, in software development there are a range of ‘actors’ who can pose these kinds of challenges to a programmer. There are even machines, in the form of software analysis tools. We identified six different kinds of challenger, with different kinds of techniques for each challenge. The illustration above and the table below summarise these techniques, giving examples of typical challengers for each.
|
Technique |
Challenger |
Summary |
|
Brainstorming the Enemy |
Fellow programmers |
Using ideation sessions with fellow programmers and others to identify both attackers and possible exploits in two steps |
|
Negotiated Security |
Product managers |
Interpreting the security risks and costs to project stakeholders in terms they can understand and use to prioritise security concerns against other organisation and project needs. |
|
Cross-Team Security Discussion |
Different programming teams |
Ensuring frequent and open communication on security problems between development teams in any way available. |
|
Security Challenge |
Security experts |
Setting up the development so that each has another person or team with a different viewpoint challenging the security and privacy aspect of assumptions, decisions and code. |
|
Automated Challenge |
Code analysis software |
Using automated code analysis, and automated security testing to create dialectical challenges to the programmers. |
|
Responsive Development |
End users |
Instigating a long-term development approach to support both security monitoring and regular updating of the apps. |
You can read more about these techniques in chapter 7 of the thesis write-up of the research – here. The experts provided a lot of information about the details of how to use these techniques, and that’s all captured in that chapter.
This ‘dialectic’ finding is quite important. It changes our attitude towards conflict. Far from regarding conflict as being something to avoid, where security is concerned we should be embracing friendly conflict, and using it to identify and improve our security software security.
Anyone for a nice argument?
– Charles