Developer Centred Security : Call for Proposals

National Cyber Security Centre, in Collaboration with the Research Institute in Science of Cyber Security

“Developer Centred Security”: Call for Proposals

Closing date: Friday 17 March 2017, 16:00

Summary

The National Cyber Security Centre (NCSC), working in collaboration with the Research Institute for the Science of Cyber Security (RISCS), is inviting proposals from academic researchers for research into the topic of Developer-Centred Security.

Working in conjunction with NCSC whilst undertaking research which is published in the public domain, RISCS has a strong track record of delivering high-quality academic research with the potential to significantly improve the field of cybersecurity. The RISCS community is multidisciplinary in nature, and includes a significant number of stakeholders in cybersecurity practice, drawn from across government and industry. The successful project will form part of the RISCS community, and will share its research outputs and join in community events.

Background of the Research Institute in the Science of Cyber Security (RISCS)

RISCS was founded in 2012, as the first of three Institutes set up by the UK Government in conjunction with the Engineering and Physical Sciences Research Council (EPRSC). Its early focus was to improve Cyber Security within organisations – both in the public and private sectors – with an emphasis on securing the UK and safeguarding UK economic prosperity. RISCS was renewed and relaunched in summer 2016, with funding for a further 5 years, now sponsored by the National Cyber Security Centre in partnership with EPSRC.

The vision is that RISCS will carry out high-quality research which advances knowledge in research areas identified as having the greatest potential to transformthe academic state of the art anduser practice. In addition, it is anticipated that RISCS will provide a focus for liaison with stakeholders from the NCSC and other parts of government and business.

EPSRC and the NCSCaspire to promote wide visibility of the outputs of RISCS in order to enable fast dissemination and, where appropriate, applicationof the researchto improve Cyber Security in the UK as a whole.

Developer-Centred Security Theme

On 24 November 2016,RISCS hosted a workshop on security in the socio-technical context of software development, as a precursor to this Call for Proposals. RISCS and the NCSC laid out the initial research themes and context for the work in the Developer-Centred Security workshop agenda.

Following input at the November 2016 workshop, RISCS and the NCSC have clarified the research objectives and scope for this Call. This topic will be funded by NCSC with an indicative budget of £0.5M over 2 years and proposals for research are welcome from applicants based in institutions eligible to bid for EPSRC funding. The public record of the workshop is attached and will be made available on the RISCS website; applicants are encouraged to study it before applying.

Both NCSC and RISCS believe that this is a broad scale research topic, with the potential to offer significant transformative value to the field of cybersecurity. We will be campaigning for more attention to be given to this topic at a national scale, and seeking additional sources of funding for further research from government and industry partners.

Context for the research

Traditionally the focus of cyber security research has been on developing new technologies and systems. In recent years, there has been an increased focus on gaining a better understanding of the end user in this context. This topic of research intends to understand the person building the software, their understanding of security and how they are supported in creating secure products.It seeks to create an evidence base of the current security behaviours from both the developer’s perspective as well as the people that influence and interact with them on a regular basis. It will also explore the tools and support that are currently available to developers, appreciating how, when and why they interact with them. This information will enable us to identify the most effective interventions that willmotivate and support developers to create more secure software from the start.

Developersrarelyhavein-depth security knowledge,little support available to ensure that the code they are delivering is secure and many other significant pressuresassociated with getting code and products to market. As a result,security is often not a high priority: previous researchfound developers experience security as“too hard, too slow and too expensive”; as a result,software may contain vulnerabilities that could be exploited with potentially significant consequences.

To just expect developers to make things secure when they face so many other demands is unreasonable. To address this issue, this research will ultimately help organisations and the cyber security industry to provide developers with more effective support which, in turn, willhelp them produce less vulnerable software more consistently.It is not intended to be focused on high integrity software, but to improve the situation generally to include mass market software on a global scale.

To understand how to realise this cyber security support for developers, the research will address four key questions. These questions define the research challenges to be addressed by the Institute and the scope of this research, and have been derived following the RISCS Workshop on Developer-Centred Security held on 24th November 2016. Notes from the workshop are attached (and can also be found on the RISCS website), and it is intended that they provide more detailed supporting information to this Call. The questions are:

• What does the Developer Profession look like currently?
• How can we improve the tools that developers use?
• How canthe security culture in the developer community be improved?
• How can we motivate developers to care more about security?

Evidence proving the effectiveness or not of different options or approaches, in different circumstances, is a key output of this research.

Other Research

Whilst only a small amount of research has been done on this topic to date in the UK and elsewhere, the intention of this initiative is to identify and build on the work that has already been done, rather than duplicating it. Similarly, there are other research initiatives that compliment this work. The topic space is large, and the intention is to align these initiatives where possible to avoid duplication of work and maximise our coverage as a community.

For instance, this work will complement the research that will be continued in RI2 - being renewed this year - which explores the effectiveness of formal specification, analysis and verification tools.

Additionally, another large (£1m) program of research has begun on this topic: “Why Johnny doesn't write secure software? Secure software development by the masses” which has been funded by EPSRC and led by Professor Awais Rashid of Lancaster University. It is anticipated that RISCS and this research initiative will communicate their intentions and outputs on a regular basis.

Other research that has been or is due to be carried out on this topic, will be referenced where relevant in this document or the accompanying write-up.

Research challenges

Research proposals should clearly address at least one aspect of these principal challenge areas. Further information elaboratingon the potential content of these research challenges can be found in the write up of the workshop on 24th November 2016 attached.

1. Characterising the Developer Profession.

The demographic of the developer community is now extremely broad. Writing code is no longer dominated by dedicated software development houses, but is now often embedded in organisations whose primary business is to deliver services and goods (such as Etsy, Amazon etc). Developers can enter the profession through a variety of pipelines and once part of the community, their knowledge and professional development strategies may also differ.Developers work in a variety of settings and their day to day tasks, interactions and prioritisation of the various pressures upon them will vary. The result is a profession with a spectrum of skills, knowledge, experience and behaviours that is more diverse than it has ever been before.

Research gathering information to understand all these differences and the variety of ways in which a developer might interact with cyber security, will provide the insight needed to evaluate where, when and what the optimum intervention points are for awareness initiatives, education and knowledge sharing and the format they should take. It will also contribute to deciding how developers can be supported best, which is elaborated in the subsequent challenges.

1. How can we improve the tools that developers use?

Developers interact with a variety of tools on a day to day basis such as development environments, APIs, open source code repositories and automated testing products. How these different tools support the developer to choose the most effectivesecurity propertiesvaries considerably. Dr Sascha Fahl et al discussed this topic in their paper: “The Developer is not the Enemy”, where they challenged the usability of cryptographic APIs. In contrast, tools such as the AcmeBot from LetsEncrypthave been praisedfor their ease of use for enabling https for websites.

Navigating security is difficult and complex to a non-security expert, and this challenge aims to understand how much supportexisting tools currently provide. By exploring the characteristics of tools that developers enjoy engaging with and respond to best, identification of the ways in which tools might be improved to support developers to make better security decisions can be carried out. The intention of this research is not to develop new tools and techniques, but to improve existing ones.

Tools in scope include:

• Code repositories
• Development Environments
• Tool ‘Accessories’ such as warning messages and security indicators
• Processes (e.g. agile, waterfall)
• Frameworks (e.g. security development lifecycle)

Not in scope are static analysis tools, which concentrate more on the verification of code rather than the development of code. Also, the application of the output of this research is intended to improve mass market rather than high integrity software development that static tools are often more applicable to. RI2 focuses on this aspect of secure code.

1. How can the security culture in the developer community be improved?

Considering security amongst the myriad of other pressures a developer needs to deal with, often at pace, is best driven from the top down but currently it seems to be driven from the bottom up. Getting senior leaders to acknowledge the importance of cyber security is an important first step to positively influencing security culture.

This research will explore the current perceptions and attitudes to securityof the various stakeholders involved in software development, and how this manifests itself in their day to day actions and conversations. It will seek to understand their influence on developer’s security behaviours and decision making, and evaluate what changes would impact security in a positive way so that realistic and practical suggestions can be made.

1. How can we motivate developers to care more about security?

Cyber Security is not something that is intuitive, especially to professionals who don’t have any background in the discipline. It is also very rarely the key driver or property of a product being developed, and will always be something of which just ‘enough’ needs to be done. Judging what constitutes ‘enough’ is difficult and, as described above, developers often have several competing pressures to manage meaning that security often isn’t given the time or consideration that it ideally needs.

This research will seek to explore the different reasons why developers are motivated or demotivated to care about various aspects of code development, identifying themes and investigatingwhat practical changes could be introduced to enable and motivate developers to spend more resource on cyber security properties.

Research Institute – way of working

The successful project will join the RISCS portfolio, with all project staff becoming community members. Representatives from the project will be expected to attend the majority of the quarterly RISCS community meetings, workshops and/or conferences. The project will be asked to present its progress at some of these meetings.

There will be the opportunity to engage directly with the NCSC during the course of the project, although the majority of the interaction is expected to be via RISCS.

The project will also be expected to supply brief progress reports each quarter, and an annual progress summary, via RISCS.

What should be in the proposal?

Each proposal must make it very clear how it addresses at least one of the challenge areas described above. Proposals should also include details of any planned engagement with ‘real world’ security.

The proposal should specifically address each of the following items:

• Background:An outline of the context of the research.
• Aim:A description of what understanding of the topic space the research is progressing and what potential impact it will have in practice.

• Relevance to the call: A description of which challenges the research addresses, and how it addresses them.
• Data:Whether the research is planning to create or make use of any specific datasets, and how they will be generated/handled.
• Field work: Whether the research will be carried out in any ‘live’ environments as opposed to lab based work. Details of the trials environments should be provided and the degree to which access has been agreed.
• Resources: An overview of the timescales, resources and structure of the research. A workplan should illustrate how these aspects combine to progress the research. The resources being used should be detailed, and CVs for named and visiting researchers included where these are known.Whether the research is planning to involve any draw on any expertise from within the security community should be described, including the nature and extent of the engagement and the degree to which it has been agreed with the appropriate people/organisations in the security community.
• Method: An outline of how the research will be carried out, detailing techniques and approaches that intend to be used. An indication of the level of previous experience of these approaches should be included.

• Potential impact in practice: How the outcomes of the research will make a difference in a real-world setting.

Application submissions should be no more than eight sides of A4 and should include a breakdown of all costs involved, including equipment, travel & expenses etc. Proposals that attempt to engage with real-world partners are welcomed.

How will proposals be assessed?

Following eligibility checks, research proposals will be reviewed by an expert Assessment Panel comprising representatives from academia, industry, and HMG. The panel will produce a ranked list of proposals based on consensus scores.

The Assessment Panel will consider the following criteria:

• Quality – this will consider the method & concept for the proposed research, and its ability to move forward fundamental understanding within the field.
• Viability – this will assess how feasible the research is to carry out, eg whether the research concept is practicable to deliver. It will take into account the difficulty of the task, the logistical factors, and the track record of team.
• Significance – this will consider the research’s potential impact on practice and its relevance to the Call.Note that the impact on practice does not have to be immediate. A long term, highly aspirational piece of research could produce a higher “Significance” score than a more tactical “applied” piece of work eg designed to produce an immediately usable tool. Neither does this preclude research which may have a ‘negative’ outcome, eg proving that a technique does not work. The proposal should outline the potential for transformative thought or progress within the cybersecurity profession, whether this be near or long term.

All three criteria will be equally weighted. However, “Significance” will have a minimum threshold, below which proposals will be rejected.

It is anticipated that a single project will be chosen for funding from this Call.

Key dates

Funding available

This topic will be funded by NCSC with an indicative budget of £0.5M over 2 years. The funding and contract will be under the NCSC’s standard terms and conditions: a draft copy of the contract can be made available on request. The research will be funded at Full Economic Cost. Budgets for attendance at academic conferences to publicise and disseminate the work should be included within the research proposal. In addition to the travel budget for attending conferences, proposals should include adequate funding for travel between academic partners within the project, and to attend the quarterly Institute meetings.