Defence Science Technology Laboratory.

Prototype for Advanced / Automated Network Defence Actions (PANDA)

Incomplete applications

5
Incomplete applications
4 SME, 1 large

Completed applications

11
Completed applications
6 SME, 5 large
Important dates
Opportunity attribute name Opportunity attribute value
Published Monday 4 June 2018
Deadline for asking questions Monday 11 June 2018 at 11:59pm GMT
Closing date for applications Monday 18 June 2018 at 11:59pm GMT

Overview

Overview
Opportunity attribute name Opportunity attribute value
Summary of the work Take the maturity of the Prototype for Advanced / Automated Network Defence Actions (PANDA) to Technology Readiness Level (TRL) 4 to support internal research projects and international collaboration.
Latest start date Friday 31 August 2018
Expected contract length Minimum of six months with a current maximum of 12 months
Location South West England
Organisation the work is for Defence Science Technology Laboratory.
Budget range £250k

Discovery Phase should be Fixed Price (i.e. user story & backlog generation).

Alpha + should be Capped Time & Materials.

About the work

About the work
Opportunity attribute name Opportunity attribute value
Why the work is being done The UK Ministry of Defence along with the commercial sector is now heavily reliant on strategic and enterprise systems both in fixed and deployable contexts.

Such systems can contain hundreds or thousands of endpoints across multiple locations, potentially in different countries and with varying levels of communication bandwidth and stability.

These systems are becoming increasingly highly dynamic and complex with every new technological innovation, and require highly skilled operators to DETECT and PROTECT from an ever increasing variety (in terms of sophistication and methods of operation) of threats.
Problem to be solved Currently this DETECT and PROTECT posture is reliant on processes that are predominately mandraulic. Increasing complexity is placing a larger cognitive burden on a limited resource.

Moreover in increasingly federated/ coalition mission environments, boundaries of system ownership and management authority are more porous and DETECT and PROTECT activities must be coordinated across operating authorities.
Who the users are and what they need to do The desired outcome is to raise the technological level of both software and knowledge of stakeholders in the area of automated network defence.

This automation will not seek to remove the human decision making process, but to reduce the burden on the operator by assimilating all the information the network is presenting and providing the operator or his commander the relevant information to allow a coherent and timely response based on policy, doctrine or operational need.
Early market engagement
Any work that’s already been done In 2014/15, Dstl funded a series of projects on Automating Cyber Defence Responses, which delivered proof of concept research proposals for tools and techniques that supported the planning and carrying out of automated responses in the protections of networks in the face of complex multi vector attacks. Follow-on work in 2015/16 specifically examined automated Course of Action (CoA) analysis.
Existing team The supplier will be working with a dedicated technical partner from Dstl for day to day interaction.

Alongside this will be a small team from the project, who will act as hosts, when or should the need to work on the software on our Porton site arises. This team operates out of their own laboratory space which is equipped to support software integration and development.
Current phase Discovery

Work setup

Work setup
Opportunity attribute name Opportunity attribute value
Address where the work will take place We would expect the majority of the work to be conducted at the suppliers own address, but there maybe times when both formal meetings and development work will take place at Dstl Porton Down, Salisbury, SP4 0JQ.
Working arrangements The supplier shall utilise an Agile development approach (e.g. Scrum). This will allow development to closely align with requirements and assist evaluation throughout the project. The supplier shall host an initial start up meeting. The supplier will need to spend time at Dstl's site and project team during the initial phase of the project (identifying and prioritising user stories). It is expected that the majority of development work will take place at the supplier’s site, but occasional visits to Porton will be necessary.

Any expenses such as Travel and Subsistence must be detailed in the suppliers breakdown of price
Security clearance Must be able to handle OFFICIAL material only.

Additional information

Additional information
Opportunity attribute name Opportunity attribute value
Additional terms and conditions DEFCON 76 (EDN 12/06); DEFCON 501 (EDN 05/17) – (NOTE ONLY TO BE USED WHEN INTERPRETING THE DEFCONS); DEFCON 531 (EDN 11/14); DEFCON 608 (EDN 10/14) ; DEFCON 611 (EDN 02/16); DEFCON 649 (EDN 12/16); DEFCON 659A (EDN 02/17); DEFCON 703 (EDN 08/13).FULL TEXT VERSIONS OF THE DEFCONS CAN BE FOUND ON THE ACQUISITION SYSTEM GUIDANCE (ASG): HTTPS://WWW.GOV.UK/ACQUISITION-OPERATING-FRAMEWORK.

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Skills and experience
Opportunity attribute name Opportunity attribute value
Essential skills and experience
  • Demonstrate with evidence, the ability to deliver without authority funded capability enhancements, for example procurement of additional ICT to support development activities
  • Demonstrate with evidence, the ability to write software in Python and Java
  • Create software to run on supported versions of Microsoft Windows (>= Windows 7) and Debian-based Linux operating systems (>= Ubuntu 16.04 LTS) without reliance on any closed-source, proprietary, software dependencies
  • Demonstrate with evidence, experience of third party technology integration
  • Must be able to produce appropriate levels of Validation and Verification documentation during the development (show supporting evidence)
  • Must be able to provide weekly unstable and monthly stable builds via a public facing (preferably Git-based) repository (show supporting evidence)
  • Demonstrate with evidence the ability to conduct software development in-house and not use a subcontractor for this task
Nice-to-have skills and experience

How suppliers will be evaluated

How suppliers will be evaluated
Opportunity attribute name Opportunity attribute value
How many suppliers to evaluate 6
Proposal criteria
  • Demonstrate experience of developing robust, high quality software solutions in demanding timeframes, within the quoted budget
  • Demonstrate expertise and experience of developing software to implement machine learning algorithms
  • Demonstrate experience of developing software in the cyber security domain / cyber defence operations in support of high threat and government organisations
  • Provide a breakdown of the team structure (please include CVs of the team members doing the work)
  • Provide estimated timeframes for the work (include Gannt chart with approximate sprint timeframes)
  • Detail and explain identified risks and dependencies. Provide details of offered approaches to manage these risk (include a Risk Register)
  • Provide a detailed breakdown of costs and include information against the following: Hours and rates. Cost of materials. Travel and Subsistence
  • Provide a breakdown of the roles within the team and the manpower hours allocated to these
  • Describe how your proposal will optimise costs and generate savings
Cultural fit criteria
  • Demonstrate with evidence ability to follow industry best practice when conducting Verification and Validation for example TickITplus
  • Demonstrate with evidence that they are able to respond to an evolving customer requirement
  • Demonstrate consistent cultural commitment to agile software development practices
  • Provide a summary of the suppliers work ethos and working environment
  • Demonstrate ability to work compatibly with Dstl
  • Share knowledge and experience with other team members
  • Be transparent and collaborative when making decisions, show evidence
Payment approach Fixed price
Assessment methods Written proposal
Evaluation weighting

Technical competence

60%

Cultural fit

20%

Price

20%

Questions asked by suppliers

Questions asked by suppliers
Supplier question Buyer answer
1. ...developing software to implement machine learning algorithms ...developing software in the cyber security domain / cyber defence operations in support of high threat and government organisations Is there a reason these weren't included in the "skills and experience" criteria used to filter suppliers? Many organisations will have developed software in Python and Java, but most of those won't have developed software in the cyber security domain in support of high threat government organisations. To what extent will these areas be considered a must-have at proposal stage - are you open to applications from competent generalists or are you seeking specialists? These areas are not a ‘must have’, but are a weighting for the assessment. Hence, an excellent proposal from a generalist could theoretically outscore a weaker proposal from a specialist. However, it should be noted that an agile software development approach is a requirement, not a weighting, so specialism in agile software development is a ‘must have’.
2. Can the Authority please state whether the funded series of projects on Automating Cyber Defence Responses in 2014/15 and the follow-on in 2015/16 were delivered in-house or by Industry? If by Industry can the Authority provide the names of the Industry partners used? Previous projects were delivered by industry & academia. Dstl acted as a technical partner, providing guidance and direction, but did not complete any of the work in-house. Work conducted in 2014/15 was by Cyberlytic Ltd, Deep Sky Blue Solutions Ltd (now Deep3), Insighlytics Ltd, Noumena Research Ventures, RJD Technology Ltd, Thinking Safe Ltd, University of Oxford - Cyber Security Centre and the Faculty of Technology – University of South Wales. Work conducted in 2015/16 was completed by Deep Sky Blue Solutions Ltd, the University of Oxford – Cyber Security Centre, Insighlytics Ltd &the University of Warwick / Thinking Safe Ltd.
3. Would the Authority support a teaming approach if all members of the team are able to contribute to the software engineering activities? No. The authority requires a single supplier that can provide a software development team with experience of delivering agile software development through mature internal processes and culture. A teaming approach introduces undesired and unnecessary risk.
4. With respect to providing evidence of building software to run on Windows and Debian-Linux, does this relate to the Operating Systems of the servers on which the system/prototype will run or the Operating Systems of end users/cyber analysts? 2. Please clarify the definition of a "public-facing" repository? Does this relate to an Open Source style public-facing repository as in a public GitHub repository that anyone with a GitHub account can access or does this refer to a private GitHub repository shared between Dstl, its partners and the supplier? 1. At this stage we do not want to specify a software architecture for the prototype, but we would consider evidence from both cases. The driver behind including this requirement is to ensure that the operating system does not overly constrain the deployment of the software.

2. This statement relates to the latter. Source code should be hosted on a private git repository, accessible via the Internet. Access should be limited to Dstl and the supplier. Any additional access should be agreed with and approved by Dstl.
5. The essential criteria asks "Demonstrate with evidence, the ability to deliver without authority funded capability enhancements, for example procurement of additional ICT to support development activities". Can you be more specific please? This means that as the supplier is expected to be a proven, experienced software developer they are expected to have the requisite infrastructure and tools etc. Hence, there is no provision for the authority to uplift their capability in order to deliver this work. The supplier is expected to have the capability to provide internet facing services such as a version control repository, all hardware and development tool licenses etc.