Design security into your code. Don’t just hope for the best
If someone constructed a suspension bridge by guessing the steel cabling sizes required and then loading the deck to see whether it collapsed, you would be unlikely to suggest that he was a great civil engineer. And if a lift manufacturer sized their motors by trying them to see whether they caught fire, you wouldn’t expect their electrical engineers to win many awards.
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.