“Part of the problem is just culture,” he said. “A lot of code is written in a ‘throw it together, test, debug and it’s good enough’ fashion. We’ve never been satisfied doing that on avionics code, but that care isn’t applied in other areas where you’d expect it to be applied, like automotive software and medical software.”
While Ada has long been the choice for systems that cannot have any bugs, it’s only recently been seen as a security solution, especially now that embedded control systems on planes and in cars are now more vulnerable to attacks, said Dewar.
“We haven’t lost a life on a commercial airline due to software bugs,” he said. “On the other hand, we have only just started to worry about security in avionics software. Boeing issued a warning on the 737 to protect it from security flaws. It’s certainly true that using a language like C makes life harder. Nobody should be saying it’s impossible to write secure software in C, but it certainly makes life harder.”
Dewar said that the traditional software development discipline of proving an application is bug-free could be a good method of ensuring security for applications. “The air traffic control system for England is mathematically proved to be free of buffer overrun errors or overrun errors,” he said. “They cannot occur because [it is] mathematically proven that they can’t happen.”
Proofs aren’t exactly child’s play, but they can be a good way to reassure yourself and your bosses of the security of the software. “Proof of correctness is a really interesting aspect of [software security],” said Dewar. “It is not a magic bullet: You can have a bad specification and carefully prove your software matches that bad specification. But it’s helpful to prove code is free of buffer overrun errors, which is the most common vulnerability of C code. It’s something that can be avoided.
“Ada is not the only language where it’s just not possible to overrun memory arrays. That’s all checked at runtime. It’s only a partial solution, and it’s not helpful if you’re driving a car and having a message come up saying something’s gone wrong with the software. But with something like Heartbleed, it would be better if that software crashes with an error.”
Enforcing at code time
A few of the more popular solutions for security in the development life cycle are static code analysis tools like Coverity, FindBugs and Veracode. Another approach advocates the use of in-IDE enforcement tools like Klocwork and Cigital’s SecureAssist. But all of these tools have their limitations and strengths.
“Most static analysis tools say I found lots of potential bugs, but I haven’t found all of them—maybe 90% of them,” said Dewar. “That’s not terribly convincing. The immediate question [of] ‘What about the other 10%?’ is a serious one for security applications. These tools that help find bugs are not the answer. You need sound tools that, when they say there’s no possibility, there’s no possibility.”
That’s because one of the traditional problems with static analysis tools is that they don’t catch everything, and that they can throw false positives.