Abstract
Purpose This paper aims to describe an effort to provide for a robust and secure software development paradigm intended to support DevSecOps in a naval aviation enterprise (NAE) software support activity (SSA), with said paradigm supporting strong traceability and provability concerning the SSA’s output product, known as an operational flight program (OFP). Through a secure development environment (SDE), each critical software development function performed on said OFP during its development has a corresponding record represented on a blockchain. Design/methodology/approach An SDE is implemented as a virtual machine or container incorporating software development tools that are modified to support blockchain transactions. Each critical software development function, e.g. editing, compiling, linking, generates a blockchain transaction message with associated information embedded in the output of a said function that, together, can be used to prove integrity and support traceability. An attestation process is used to provide proof that the toolchain containing SDE is not subject to unauthorized modification at the time said critical function is performed. Findings Blockchain methods are shown to be a viable approach for supporting exhaustive traceability and strong provability of development system integrity for mission-critical software produced by an NAE SSA for NAE embedded systems software. Practical implications A blockchain-based authentication approach that could be implemented at the OFP point-of-load would provide for fine-grain authentication of all OFP software components, with each component or module having its own proof-of-integrity (including the integrity of the used development tools) over its entire development history. Originality/value Many SSAs have established control procedures for development such as check-out/check-in. This does not prove the SSA output software is secure. For one thing, a build system does not necessarily enforce procedures in a way that is determinable from the output. Furthermore, the SSA toolchain itself could be attacked. The approach described in this paper enforces security policy and embeds information into the output of every development function that can be cross-referenced to blockchain transaction records for provability and traceability that only trusted tools, free from unauthorized modifications, are used in software development. A key original concept of this approach is that it treats assigned developer time as a transferable digital currency.
Highlights
Software has become the most significant component of a modern combat aircraft’s capability
It is the intention of PARANOID to complement and enhance above such efforts, not just by more and better adherence to the conventional cybersecurity best practices such as the Risk Management Framework (National Institute of Standards and Technology, 2017) and associated controls (National Institute of Standards and Technology, 2013), but rather to provide the ability to prove at the point-of-load, on a module-wise basis, that said the software was developed on tools not subject to unauthorized modifications and that it was developed by approved developers on approved development hosts on the approved schedule
Having a BMP for each source code file corresponding to a function in the object import list with regard to the linking operation (Samek, 2018), the blockchain-based authentication strategy would look like this: A securely implemented checking process would sequentially sweep through the upgrade Operational Flight Program (OFP), whereby each binary module with its specific embedded signature block as shown in Figure 6, would be processed against the BMP, likewise this would occur with the previous OFP, such that for the corresponding sections, based on the associated BMP, it could be proven module-wise, as in Figure 8, that the upgrade OFP is derived from the previous OFP
Summary
Software has become the most significant component of a modern combat aircraft’s capability. It is the intention of PARANOID to complement and enhance above such efforts, not just by more and better adherence to the conventional cybersecurity best practices such as the Risk Management Framework (National Institute of Standards and Technology, 2017) and associated controls (National Institute of Standards and Technology, 2013), but rather to provide the ability to prove at the point-of-load, on a module-wise basis, that said the software was developed on tools not subject to unauthorized modifications and that it was developed by approved developers on approved development hosts on the approved schedule This capability involves the utilization of blockchain, making each development action a transaction such that module-wise authentication is based on vetting blockchain transaction records. PARANOID enforces the TECHS conditions with three primary components: a secure development environment, a blockchain and an authentication mechanism
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
