Dstl

About the Organisation

The Defence Science and Technology Laboratory (Dstl) is the science inside UK defence and security.

Dstl is an executive agency of the Ministry of Defence (MOD) providing world class expertise and delivering cutting-edge science and technology for the benefit of the nation and allies.

Web Links

https://dstl.gov.uk/

Projects with Dstl

The projects below have either provided by Dstl or Dstl is the client of the project.

System-of-system risk assessment of a CI/CD pipeline

Creating a risk model for incorporating Dev[Sec]Ops into software development, to form a single CI/CD pipeline for software creation

Problem Definition: Multiple organisations might collaborate on the creation of a software product, but have different expectations around trust and information classification. If the organisations adopted Dev[Sec]Ops then what would be the risks of such organisations forming part of a single CI/CD pipeline.
Additional Information: Creating a risk model and, if there isn’t a repeatable/pre-existing process for coming up with it, a tool-supported process for incorporating Dev[Sec]Ops into software development, to form a single CI/CD pipeline for software creation
Suitable for:: Business Information Technology Computing Computer Science Cyber Security with Digital Forensics Cyber Security Management Networks and Cyber Security Software Engineering
Artefact Type (Desired Output): Other (Ask Us)
Project Supervisor: There is no set supervisor for this project, which means you can freely approach any staff member in the department about being your supervisor for this project.
External Organisation (if Applicable): Dstl
Expected Involvement from the Organisation: Client will be contactable for the occasional meeting to look over / comment on any models.

View more View less

Open Project Page

NIST SP 800-37 User Interfaces for non-security experts

This project should deliver a software prototype to help teams collect, analyse, and manage PREPARE step data obtained when applying NIST SP 800-37. To reduce the timeline for developing such a tool from months to weeks, the back-end of the tool could be based on the open-source Computer Aided Integration of Requirements and Information Security (CAIRIS) platform. Because of the assumptions made about those using CAIRIS, the existing CAIRIS user interface (UI) won’t be suitable. As such, the focus of the project will be designing, developing and evaluating a UI that delivery teams could use on a day-to-day basis.

Problem Definition

NIST SP 800-37 is an approach for ensuring security embedded into the design and operation of new and existing systems from the outset and through life. Responsibility for implementing this approach rests not with accreditors, but with the teams responsible for delivering and operating the systems.

Because the availability of substantial security expertise on project teams might be limited, responsibility for many risk management tasks falls on those with expert domain knowledge, but comparatively limited knowledge of security. In theory, this situation should not inhibit the approach; many of the ‘PREPARE’ steps don’t assume they are completed by security experts. In practice, however, non-security experts would benefit from tool-support to guide the capture, management and analysis of collected risk data. Such tool-support should also support the means of outputting risk data in a format that would help accreditors obtain assurance that a project team is properly following the approach.

Additional Information

Student would need to be willing to pick up NIST SP 800-37 and CAIRIS. To support the later, some experience with SQL, Python and JavaScript / Vue.js would be useful.

Suitable for:

Artefact Type (Desired Output)

Developmental Solution

External Organisation (if Applicable)

Dstl

Expected Involvement from the Organisation

Client should be contactable for the occasional meeting to look over / comment on any artefact/s.

View more View less

Open Project Page

System-Level Fuzz Testing

How feasible is guided fuzz testing to exercise vehicle-based software within a simulated environment.

Problem Definition

The main aim of the project is to learn about the difficulties of implementing a system-level fuzzer, as well as the benefits that it may provide. A secondary (significantly more complex) aim would be to have a way of identifying scenarios that result in radically different system behaviour for two different versions of the software under test.

The above figure roughly indicates the sort of prototype that a student might produce.

Additional Information

The simulated environment, vehicle representation and (an initial version of the) software under test could be provided from a number of sources. Examples include:

AirSim:	https://microsoft.github.io/AirSim/
ArduPilot:	https://ardupilot.org/
CARLA:	https://carla.org/
Gazebo:	https://gazebosim.org/home
TORCS:	https://sourceforge.net/projects/torcs/

It may be possible to use something like American Fuzzy Lop (https://github.com/google/AFL) or Dakota (https://dakota.sandia.gov/) to manage the iterative process of measuring coverage (for the software under test) and deriving new test scenarios. Alternatively, or additionally, bespoke approaches, perhaps exploiting Machine Learning (ML) could be developed.

Suitable for:

Artefact Type (Desired Output)

Other (Ask Us)

External Organisation (if Applicable)

Dstl

Expected Involvement from the Organisation

The Dstl customer is happy to answer available questions. He is also happy to visit BU if it’s useful.

View more View less

Open Project Page