Angus Marshall at the University of York, UK has recently put together a survey for digital forensics tool developers and is looking for respondents. You can find the survey here.
The general problem of digital forensics tool verification and validation is of increasing importance, and this has been widely recognised by industry and government, particularly in the following reports.KTN Report : “Digital Forensics Capability Review” (2013). This identified that development and adoption of new tools was considered a significant challenge, and flagged up issues relating to quality management.
ISO/IEC 27041:2015 “Guidance on assuring suitability and adequacy of incident investigation method” includes a suggestion that tool verification data can be used to support validation methods, where requirements can be mapped, but there is no reference to supporting evidence for this.
The unofficial report “UK ISO 17025 Digital Forensics Survey April 2017: Results” (PDF), in spite of some problems with the analysis carried out, highlights a number of perceived issues with the requirement for method validation, including a perception that many labs will be testing the same tools for the same operations, resulting in an unnecessary duplication of effort.
Now I’m running a pilot project to look at how/if the requirements identified on both sides can be mapped to show a concordance between validation testing needs and provider verification testing results, and I have interest in this from bodies who are working on ISO 17025 and ISO 17020 compliance in the UK.
However, I’ve uncovered a possible disconnect in the way the two groups handle requirements capture and documentation – but my sample is too small to be sure that it’s real. The user side is relatively simple to deal with, but I need a better understanding of how tool producers are doing things. This short survey (7 questions) is intended to allow me to get a level of understanding of common development methods and requirements capture/documentation. I’d welcome input from anyone involved in tool development. No particular tool, company or person will be identified in the final reports.