Design security into your code. Don’t just hope for the best

And yet these approaches are exactly analogous to how security critical software developers often approach their work. 

The development cycle for traditional security markets is a largely reactive one, where coding is developed mostly on an informal agile basis, with no risk mitigation and no coding guidelines. The resulting executables are then subjected to performance, penetration, load and functional tests to attempt to find the vulnerabilities that almost certainly result. The hope, rather than the expectation, is that all issues will be found and the holes adequately plugged.

Safety critical software development belongs to a different world, with a process that would be far more familiar to exponents of the more traditional engineering disciplines. A process that consists of defining requirements, creating a design to fulfil those requirements, developing a product that is true to the design, and then testing it to show that it is.

This paper argues that whether their product is safety critical or not, it is time for security critical software developers to embrace that same, sound engineering lifecycle. In doing so, it will compare and contrast the difference in focus between CERT C’s application centric approach to the detection of issues, versus MISRA’s ethos of using design patterns to prevent their introduction. It will advocate the use of reactive penetration and load tests to prove that the product is sound, rather than to find out where it isn’t.

In short, it challenges secure software developers to embrace the concept that it is far better to design in security rather than hope to remove insecurity.

A full LDRA white paper on designing in security from the beginning of a project can be downloaded below.