Blog

Developer-centred security: Developers Den

The second session of the February 2018 workshop was a Developer’s Den, in which three people developing security tools or services to support developers presented their efforts to date in search of constructive criticism. The other sessions from this workshop are: introduction and summary, reverse panel discussion, and lightning talks.

This part of the day was designed to stimulate a feedback loop, and begin to pull together a toolbox of techniques and products to support developers that have been reviewed by the DCS research community. Four tools and services were presented:

The panellists included researchers Helen Sharp (Open University), Awais Rashid (Bristol), Yasemin Acar (Leibniz Uni Hannover), Sascha Fahl (Leibniz Uni Hannover), and Manuel Maarek (Heriot-Watt), and developers DXW founder Harry Metcalfe and Michael Brunton-Spall

Secure Code Warrior
Secure Code Warrior co-founder John Fitzgerald has spent 14 years working in cyber security, including a significant period of time with SANS. SCW focuses exclusively on two areas: network security and people. Around 2010, he saw people becoming the key attack vector. In 2012, after of extending the SANS platform into different verticals, one of which was developers, he began asking why we keep doing the same thing over and over again and whether we’re solving the right problem if, as ten years of reports have consistently found, 35% of breaches are caused by software vulnerabilities.

Quality assurance provided a role model: 20 years ago, when it became unaffordable to fix functional problems after release, people set up quality assurance processes, and now developers write unit tests before they tackle the program code, so they know what to test against. Fitzgerald asked why we don’t do this in security? That became the genesis of SCW.

Fitzgerald wants to make developers the first line of security. It is, however, challenging. In Meet the Modern Learner, Deloitte found that a typical employee is allowed to spend 1% of their time on training and development – that is, 24 minutes in a 40-hour week. Security is seen as a problem for the security team. Anything invested in developers is seen as something that has to be repaid in productivity. The goal with Secure Code Warrior was to change the whole game by turning developers into security superheroes and avoid, rather than discover, vulnerabilities. Fitzgerald reasons that this approach also ought to translate into savings, as the cost of fixing security bugs rises the later they are found in the development process.

SCW is a hands-on learning platform designed to be competitive, engaging, and language-specific. It includes a number of tools: tournaments, training, learning, a coaching plugin, metrics, and assessments. The coaching plug-in, known as Sensei, sits in the integrated development environment and acts like a spell-checker for security while developers are coding, checked against the organisation’s own guidelines and the top 20 list of vulnerabilities. With security costs escalating, Fitzgerald believes it’s important to stop writing insecure code, rather than adding cost by finding the vulnerabilities that result from that underlying problem.

The panel raised a number of issues: the user interface; the importance of incorporating community; time pressures; how to integrate this tool into cultures that share knowledge and support informally, rather than going through formalised training; the auto-detection feature’s error rates and the dangers of over-relying on its accuracy; and developers’ general dislike of training, no matter how “engaging”. In agile development the cost of fixing bugs no longer rises over the course of development unless you have to restart from the beginning. Finally, often the problem is not the code developers write but the libraries they use, as Matthew Green discusses in Developers Are Not the Enemy.

UK Hydrographic Office: security champions
Neville Brown runs the software engineering team at the UK Hydrographic Office, part of the Ministry of Defence that provides sea charts and marine geospatial information. UKHO’s biggest customer is the Royal Navy, but it is also a trading fund. Of its 850 staff, 50 are software engineers.
Improving security, which UKHO decided this year it needs to do, poses several challenges. The office has a large variety of teams, technologies, and security contexts. On the defence side, UKHO can afford to slow things down as much as needed to ensure things are really secure, but the commercial side is subject to the usual market time pressures. Therefore, no one size fits all the office’s circumstances. Brown can’t impose standards or practices – either these slow down the commercial side or make the defence side insecure. In addition, today’s agile development process means there is no obvious time for experts to give advice and few documents to review, and teams self-organise. Therefore, expertise needs to be situated within each team, tailored to each team, compatible with agile development, and rooted in the way developers work.
UKHO is therefore in the process of setting up security champions, giving some developers extra skills and responsibility to coach and influence the team to adapt their processes – “like scrum masters in security”. The champions themselves also work together as a virtual team.

So far, Brown has learned that there are plenty of people interested with a mix of motivations: career development and advancement, money, even the desire to create secure code. A few seem more interested in hacking, which has warned Brown to ensure to plan for that. For their planned April launch they need help – speakers, games, and activities; they are struggling to find a canonical set of training and body of knowledge.

Panellists suggested that while the dual roles make sense, a difficulty may be ensuring that the security champions have enough time to do all of both parts of their job plus maintain the security skills they’re championing. It’s a common problem that these roles are set up with enthusiasm but over time the champions find themselves charged with additional responsibilities without the accommodation they need. In addition, some of the important aspects of this job are simply boring – an example given was SQL injection, which is a big problem, but a dull one. In addition, motivation can be a problem; will money and time be allocated for teams to implement the recommended security improvements? In this sense, the state of security today is similar to the state of user experience design 20 years ago; champions were one of the ways that was solved, so some of the other methods they used might also be applicable here. A final issue is that the champion model works well when the champions are right, but when they’re wrong people will still follow them – a problem that may increase over time as the champions have less and less time to improve and update their own skills. For that reason, developing communities within organisations that can improve security may be a better approach than focusing on a few charismatic individuals.

In work-in-progress studying a variety of interventions, Charles Weir, Ingolf Becker, and Angela Sasse are finding an early clear result that the team doesn’t necessarily learn from the champions. Champions may work if you already have someone who knows what they’re talking about, but there isn’t yet a good way of training up those advocates and keeping them motivated and rewarded. The researchers are working on ways to encourage and train advocates who can go from team and team spreading the word and solving many problems instead of just one. Champions may be best viewed as one tool among many; the greater mission is to make every software developer slightly better at security. Weir gave more detail about this project in the following session of lightning talks.

ThoughtWorks: Sensible Conversations
The idea behind Sensible Conversations, said Jim Gumbley, principal security engineer at Thoughtworks, is to build capability. Traditional approaches like threat modelling and risk assessment are genuinely hard and often leave developers confused. Gumbley’s goal for the last year has therefore been to make threat modelling simple. Hence Sensible Conversations, which gathers a cross-functional group to share their understanding of what needs to be protected and why; what the real threats are; and where there might be technical exposure. Then the group can prioritise the most valuable next steps.
Getting the scope right is crucial to ensuring that the discussions stay on track. As facilitators to identify scope, ThoughtWorks uses a component architecture diagram and “asset” cards. There are also threat cards – for example, “A random botnet or script kiddie mounts an automated attack on the system”; a GDPR card is a recent addition. Using these as cues, the team explores the likelihood and impact of threats and prioritises them for further discussion. The group then splits into groups and uses exposure cards and checklists derived from OWASP and NCSC guidance to assess the organisation’s exposure and what its workforce needs to improve. The groups then reconvene, report their findings, and agree three next steps.

To date, every such exercise ThoughtWorks has run has produced valuable security next steps and has proved a good way to connect security and delivery teams.

ThoughtWorks is still refining and simplifying this approach, and is looking for feedback. It intends to use a train the trainer model to create more facilitators and open-source the materials.

A panellist asked how this approach would help security problems become visible to, for example, an agile team. Gumbley noted that sometimes teams don’t know what a particular threat – cross-site scripting, for example – is, and their next step may be to go learn about it. Or the groups may simply say that whenever they look at a story concerning the database they have to take threats like SQL injection into account.

Another panellist asked about measuring the resulting improvements. ThoughtWorks has found some patterns across the 20 of these sessions they’ve run across a variety of industries. People consistently ask for copies of the cards or help writing stories. In one case, a ThoughtWorks discussion got a project cancelled because a P&L manager discovered that two security groups were each spending a couple of hundred thousand pounds trying to fix the same problem. In every case, they’ve found the effort produces awareness, insight, and action. Getting people to participate has not been difficult; they’re usually asked to do so by the project manager.

One question was how to ensure that the discussions are not building false confidence, as the Dreyfus model of learning shows that people consistently overestimate the amount they’ve learned in formal training. ThoughtWorks, however, isn’t trying to teach security but to raise awareness.

Choosing winners
The panellists were asked which of these efforts they would invest in. All three met general approval. However, Sensible Conversations got the most votes, followed by Secure Code Warrior. As Helen L noted, a lot depends on what kind of return an investor is looking for. Sensible Conversations is the most holistic and might be the best choice for organisations struggling with a security flaw in their business processes instead of a vulnerability in newly-written software. Secure Code Warrior is the most overtly investor-friendly because it offers a tool that can be sold.

About Wendy M. Grossman

Freelance writer specializing in computers, freedom, and privacy. For RISCS, I write blog posts and meeting and talk summaries

2 comments on “Developer-centred security: Developers Den

  1. Pingback: Developer-centred security: Workshop introduction and summary | RISCS

  2. Pingback: Developer-centred security: reverse panel | RISCS

Comments are closed.